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From the Editor 


I recently had the pleasure of visit- 
ing a site owned and operated by the 
VE2RM radio club in Rigaud Quebec 
(pronounced REE-GO). VE2BMQ, 
Burt and VE2EK, Dino gave me a tour 
and talked with N2MGI, Matt, and I 
extensively about technique, promo- 
tion, documentation and about the 
people involved in the project. 

The site at Rigaud Mountain is a 
VHF repeater operator's dream. The 
building, tower and property are ideal 
for repeater and packet work and are 
owned by the club. They lease tower 
space and a lesser building to com- 
mercial vendors to help pay for the site. 
Tower is 130 feet of first class hard- 
ware. It looks very commercial but 
except for the lowest antennas it’s all 
ham. Even the tower lights flash in 
Morse Code. 

Now, while I'm usually pretty strict 
about talking about vaporware (any- 
day-now projects) I was convinced by 
the progress that Burt and associates 
have made that they are definitely not 
fooling around. Burt is a meticulous 
machinist and technician and has 
constructed some very impressive 
pieces of equipment. Dino has come 
up with some nice drawings and pre- 
sentation materials for the packet 
project and some excellent support 
materials for TheNET tinkerers. Dino 
supplied me with copies to photocopy 
into the Quarterly and you'll find them 
elsewhere in this issue. 


involves tying together existing serv- 
ers and TheNET nodes through a UHF 
repeater at the Rigaud site. He 
showed me the repeater hardware they 
are going to be used. For preliminary 
testing they've got a non-duplex radio 
running. This allows the servers to get 
on line now while Burt finishes up the 
repeater. The project involves getting 
one additional node site on line at 
Moose Creek Ontario. That site would 
tie Potsdam, Canton and Ogdensburg 
into Rigaud and potentially tie into 
Ottawa as well. 

Having seen the existing literature 
that Dino had created I suggested that 
he duplicated his map into three ver- 
sions: a this exists now version; a cur- 
rent projects version; and a what we 
really want version. The map that is 
printed in this Quarterly is a compen- 
dium of what regional packeteers have 
told Dino about the near future. 

I'm looking forward to massive 
progress in the northern New York, 
Ottawa and Montreal region. This is 
especially true as I live very near the 
Potsdam node! 

I'm looking for article submissions 
for the Summer Quarterly! Address all 
correspondence to me at 20 Clinton St. 
Potsdam NY 13676 or phone me at 
315-268-6288. I have modem equip- 
ment so we can pass things over the 
phone as well. My Internet address is 
torbortc@clutx.clarkson.edu. 


What is TCP/IP? 


Transmission Control Protocol/In- 
ternet Protocol. TCP/IP defines a 
protocol suite. TCP/IP is a system of 
messages sent between computers, via 
radio (or telephone, or wire) that en- 
able the computers to exchange data 
meaningfully. Where AX.25 is a pro- 
tocol that defines how two TNCs can 
communicate, either directly or via 
digipeaters, TCP/IP is a protocol suite 
that defines how two computers can 
communicate, over wire line, telephone 
with modems, two or more TNCs, 
NET/ROM, TheNET, ROSE, etc. etc. 
TCP/IP is called a suite of protocols 
because it actually includes hundreds 
of different message types and re- 
sponse procedures for dozens of differ- 
ent purposes. 

Defined in TCP/IP as commands 
(and separate protocols) there are 
TELNET, FTP, SMTP, FINGER, 
PING and others that are of direct use 
to the user. 

TELNET establishes a real time 
two way interactive connection be- 
tween a user at his own computer and 
another remote computer. This lets 
the user command the remote machine 
as if he were sitting at the keyboard 
of the remote machine. This is similar 
in effect to how an AX.25 user per- 
ceives TheNET and BBS operation. 

FTP or File Transfer Protocol is a 
customized command set for getting or 
putting files on a remote computer 
from the user's computer. Files may 
contain non-text information. This is 
a key feature of TCP/IP for amateur 
packet radio. 

SMTP or Simple Mail Transfer 
Protocol is a system for automatically 
routing multi-line messages from one 
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Minutes of 2nd Quarter 
Board of Directors 


Meeting April 13 1991 


The meeting was called to order by 
Rich, WB2JLR, as chairman at 
10:20AM. The meeting was held at the 
Keene NH fire department. It will be 
noted at this time that Lindsay, NRIN 
who is one of the board members, was 
sitting at the back of the room and re- 
mained there throughout the meeting. 

Rich reminded all present that the 
meeting was open to all voting mem- 
bers or to other people by invitation 
from a board member. Only the board 
members may vote on the issues as per 
the NEDA Constitution. Non mem- 
bers and non-voting members may join 
or upgrade during the first break. 

Rich inquired as to rules governing 
the use of the building that the meet- 
ing was held in. Someone responded 
“Don’t set any fires!”. Dana asks if it 
is all right to shout “Theater” in a 
crowded fire hall? It was generally 


agreed that that was OK. 
Attendees: 

Dana Jonas WA2WNI E NY 
Rich Place WB2JLR W NY 
Linds Collins NR1N S NH 
Cal Stiles W1JFP S NH 
Jim Wzorek KIMEA W MA 
Kevin Wright WA2VAM C NY 
Cal Calvito WAIWOK S NH 
Chan Eddy KA10U S' NH 
Arny NiIBAC S NH 
Bob Seger WB2QBQ E NY 
Bob Lafleur NQI1C W MA 
Russ Allister WAITLN S NH 
Dave N1FCC C MA 
Fred Donaldson NIEZD C MA 
Dexter KY1M C MA 
Herb Salls WB1DSW S NH 
Michelle Wright N2IDK C NY 
Secretary’s report: 


WB2JLR moved that the minutes 
be accepted as published in the Win- 
ter Quarterly. WA2WNI seconded. 
Passed 


Treasurer’s report 

Verbal Summary given at the 
meeting by Herb Salls, treasurer was 
asked to deliver a printed copy to the 
editor. 

Herb remarks that membership is, 
as usual, on an increase. 

So far only 10 members have failed 
to renew when their membership ran 
out. 


Continued on page 27 
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Herb reports that 4 orders for 
Hexipus boards have come in. 

NEPRA has paid $100 to renew 
their ‘club’ affiliation with NEDA. 


Opening Balance ag hg Bes 
Incoma 
Interest 47.62 
Dues 1444.54 
Hexipus Boards 188.80 
Total Income 1680.96 
Expenses 
Printing 645.79 
Mailing 438.36 
Hexipus Project 1052.54 
Operating 95.00 
Total Expenses 2231.69 
Closing Balance 4/22/91 
2236.42 
BBS Committee report, Jim 
KIMEA 
G8BPQ hooked to Hexipus 


Jim reports that KIMEA, WB2JLR 
and WB1DSW have managed to make 
PC based servers which run MSYS or 
G8BPQ talk direct to the Hexipus us- 
ing a pair of transistors to invert the 
control lines from the PC. This makes 
it possible to add ports to a server for 
the cost of a TNC, using only one serial 
port on the PC for N ports. Also this 
lets a node owner add a server to an 
existing node for the cost of a pair of 
transistors using one serial port on the 
server PC. Jim mentions that GBBPQ 
works much better with a TheNET 
TNC than with a KISS TNC. 
WB4HFN DOSgate 

Jim reports that WB4HFN is run- 
ning a DOSgate available from 
KNGSTN on 145.05 and MTUNC on 
223.58. 

WINY node back on line 

WINY is back up with a real node 
again but had to change his link to the 
BERK repeater from 25 watts omni to 
5 watts with a 19 element beam due 
to the coordination mishap which 
caused the local ATV repeater to have 
overlapping spectrum with the 
WALTPP BERK repeater. This solu- 
tion seems to work. 

WAI1TPP MSYS 

Herb WAITPP is playing with 
MSYS at his node site and has recently 
upgraded to a version that will allow 
.cc files which might be useful to the 
club for handling NTECH/NBOD/ 


Summer Board Meeting 
July 27, Oneonta NY 


The meeting will be called to order 
at 10AM, July 27, 1991 at the SEMO 
bunker in Oneonta NY. The meeting 
is hosted by Don Russ, N2CZL and the 
Eastern District Office of New York 
State Emergency Management Office 
(NY SEMO). Agenda items should be 
submitted to W1JFP @ WIJFP. 
NH.USA. The meeting is open to all 
NEDA voting members. Memberships 
and membership upgrades are avail- 
able at the meeting. As this is a board 
of directors meeting the function of the 
meeting will be primarily administra- 
tive. 

The meeting site is under 2 hours 
from Binghamton or Albany. To get 
there from either direction start on 
Interstate 88 heading for Oneonta. 


Directions: 

Get off Interstate 88 at exit 15 for 
Rt 23 south. 

This will take you down the James 
Letis Highway then Main Street and 
then Chestnut Street. Follow Rt 23 
signs as you will be making several 
turns! 

Finally turn right onto West Street. 
This will be at a traffic light with a 
Pizza Hut takeout, a Daily Star 
Newspaper and a U-Tote-um Laundry. 

Follow West Street for a couple of 
miles past the colleges, keeping an eye 
out for the large radio tower on the left 
which stands at the SEMO bunker. At 
the "Oneonta Job Corp. Center" sign 
turn left. 

You will pass several buildings 
which are part of the Job Corp. Behind 
the buildings is a fenced in parking lot 
which is for the SEMO underground 
bunker. Park theré. Walk into the 
tunnel. 


Talkin 
Talkin on 146.85 repeater and 
145.23 repeater. 


Overnight info: 

Holiday Inn Rt 23 south side is 607- 
433-2250. Single is $76. Double is $84. 
The price is high because it is tourist 
season. There are cheaper places 15 
minutes further away. Contact 
N2CZL, Don, at 607-967-6208 for al- 
ternative lodging. There are camp 
grounds aplenty. 

The meeting will be called to order 
at 10:00 AM. 


Network Development in 
the Ottawa Area: 
1991 Update 


Barry McLarnon, VE3JF 
Ottawa ARC Packet Working Group 


The Local Ottawa-Area 
Network 

The Ottawa area is served by one 
major node site, plus a number of 
subsidiary nodes. The major "hub" 
site, at Carleton University, is the 
home of the Hydra packet switch. 
Hydra actually consists of two separate 
systems. The switch itself ("hydra- 
gw"), which is a PC AT running KA9Q 
NOS, currently has four ports. Two of 
these are 9600bps serial interfaces into 
the 2m NET/ROM nodes OTTAWA 
(145.07 LAN) and CAPITL (145.01). 
The third port uses an Ottawa PI 
board to interface into the 56Kbps 
LAN, which is served by a full duplex 
cross band repeater (220.55 in, 433.44 
out) at the same site. Finally, there is 
an ethernet port which is connected to 
the Carleton campus ethernet. Also on 
the ethernet is the second part of Hy- 
dra, a Sun-2 workstation, which is a 
Unix system with a large amount of 
disk storage. This system will be the 
platform for developing various ser- 
vices for the amateur packet commu- 
nity. In addition to various servers 
such as on-line callbook lookup, the 
possibilities include a gateway into the 
Internet itself. 

The 56Kbps full-duplex network is, 
as far as we know, the only one of its 
kind in the world. It began as a high- 
speed LAN for the "power users", but 
it has evolved to a combination LAN/ 
local backbone network. This goes 
against the conventional wisdom of 
keeping LANs and backbones sepa- 
rate, but it is successful because there 
are no hidden transmitters, and the 
capacity is more than sufficient to 
handle both functions. When the 
56Kbps network begins to get con- 
gested, our plan is to "twin" the cross 
band repeater with a second one, using 
additional 100kHz channels in the 
same bands. It is remarkably simple 
to add a second repeater in this way, 
since the antennas and RF gear can be 
shared between the two repeaters, 
with power combining/splitting done at 
the 28-30Mhz IF of the 56Kbps mo- 
dem. 

The 56Kbps network provides the 


Constitutional Change 


At the 1st Quarter Board meeting 
two items were brought to the board 
for consideration as changes to the 
NEDA constitution. These were: 

1> A proposal to make the annual 
elections by mailed ballot with the 
elected officers to be announced at the 
general session. This proposal was 
submitted by Jim Wzorek - KIMEA. 

2> A proposal to eliminate the re- 
quirement for a general session. 

These items will be addressed and 
details discussed at the 2nd Quarter 
Board meeting. Anyone with input 
should attend this meeting and make 
their opinions known. 

—WA2WNI 
—NEDA Secretary 


NEDA TCP Experiment 


I have installed a dual-port TCP/IP 
switch at my house in Springfield 
Mass. The "user port” side of the 
switch is on the 146.415(+1Mhz) 
packet repeater located in Tolland, CT. 

There are many TCP/IP users in CT 
and W. Mass on this frequency, and 
the KA1JY-9 [44.88.0.25] switch links 
into E. Mass, NH, Southern CT, and 
Long Island. The "backbone" side of 
the switch talks directly to the NEDA 
network through an HTS-free link, and 
currently will route Rochester bound 
datagrams to IPROCH (WZ2B). WZ2B 
will route W. Mass, E. Mass, NH, CT, 
and NYLI datagrams back to my 
switch (IPWMA, NQI1C-6, [44.88. 
1.11)). 

The switch is part of an on-going 
TCP/IP experiment by NEDA to de- 
termine the feasibility of TCP/IP 
routing over the network, the impact 
it will have on other network traffic, 
and the effect of other network traffic 
on TCP/IP. The switch is not intended 
for use by TCPers over the network - 
It merely uses the network as a trans- 
port for it's IP routing. 

Initial findings are encouraging, 
although our testing has been quite 
limited at this writing. Routing be- 
tween W. Mass and Rochester seems 
to be somewhat slow, but reliable. It 
appears that TCP/IP is not overly ag- 
gressive on the network, so heavy IP 
activity should not severely degrade 
the network. 

I hope to have more information on 
our findings, and how to use the TCP/ 


—N2CZL IP switch, in the next Quarterly. 
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Ottawa from page 3 

link from the Hydra switch to the three 
Ottawa area BBS stations (VE3JF, 
VE3NAV, and VE3KYT), to users on 
two additional LAN frequencies 
(144.91 and 145.03), and to a confer- 
ence node. This network offers an easy 
means of “spreading out” the 1200bps 
2m traffic so that low-speed users can 
continue to get adequate access to the 
network. A user on the 56Kbps net- 
work can attach a 2m port to his sta- 
tion and open up a network access port 
on a new frequency for users in his 
area. This is what you might call a 
"cellular LAN" approach. In a tradi- 
tional LAN with a wide-coverage node, 
modelled after voice repeaters, you 
have too many users, too many hidden 
transmitters, and therefore many col- 
lisions and a terrible throughput. In 
a cellular LAN with more limited cov- 
erage, you have fewer users, and since 
they are located in a smaller area, less 
chance that they are hidden from each 
other. An additional benefit comes 
from the fact that the cellular nodes 
are located at home stations, and 
therefore are easier to maintain. 

The basic model for network devel- 
opment in the Ottawa area therefore 
is: 

(1) A central switch with expand- 
able capabilities, and offering access to 
various services for network users. 

(2) One or more high-speed full-du- 
plex repeaters which link the switch to 
other area nodes, as well as to some 
individual users. 

(3) A number of low-speed limited- 
coverage network access nodes, on 
different frequencies, with the fre- 
quencies reused as appropriate. Each 
frequency has one, and only one, node 
for a given "cell", so that there is no 
node-to-node traffic on these frequen- 
cies. 

The main departure from this model 
at the present time is on 145.07, where 
the OTTSAT node, which serves as the 
access point to the Calgary-Ottawa 
"wormhole’, resides in addition to the 
OTTAWA node. The OTTSAT node is 
expected to be removed from this fre- 
quency sometime in 1991, and it will 
either be added to the 56Kbps LAN or 
provided with a dedicated point-to- 
point link from hydra. 


Trunk Links to Other Areas 
Improving our links to other areas 
is a high priority for the Packet 
Working Group in 1991. Other than 
the Calgary link, all out-of-town link- 


ing remains dependent on the grossly 
overloaded 145.01 network. One rea- 
son we have been slow to upgrade 
these links (other than our preoccupa- 
tion with the local high-speed network 
and switch development) was the pos- 
sibility of obtaining additional satellite 
links, from the OTTSAT gateway to 
Montreal, Toronto, and possibly other 
points. This has failed to materialize, 
and although chances are still good 
that something may happen, it is clear 
that we can no longer afford to wait. 
Furthermore, we should not let the 
possibility of using commercial satel- 
lite channels for some of our links di- 
vert us from the goal of building an 
autonomous fully-connected amateur 
network. 

We are anxious to work with 
neighboring groups to install backbone 
links for trunking packet traffic be- 
tween Ottawa and the surrounding 
areas. We do recognize that any colli- 
sion-free backbone link, even if only 
1200bps, would be a vast improvement 
over using 145.01 and would do a rea- 
sonable job of handling the current 
volume of BBS mail. However, we also 
feel that we should aim for much 
higher performance. Not only will the 
amount of mail and bulletin traffic in- 
crease quickly as the link capabilities 
improve, but users will require more 
throughput for applications such as file 
transfers and logging into remote 
servers. We feel that 9600bps should 
be regarded as a minimum standard 
for trunk linking two major network 
nodes, and our preference would be to 
have 56Kbps on these links before 
long. We would therefore urge that 
network planners who feel that it is 
not feasible to go the higher speed im- 
mediately at least give serious consid- 
eration to providing an easy upgrade 
path. 

Providing an upgrade path involves 
two key issues: 

(1) Selecting a band (or bands) in 
which at least 100khz bandwidth 
channels are available. This means 
putting the link on a frequency above 
the 2 meter band! 

(2) Designing sufficient margin into 
the link such that it can be upgraded 
to 56Kbps without changing the an- 
tennas and feeds. 

With regard to the second point, 
there is a convenient rule of thumb: in 
order to work adequately at 56Kbps, 
the link will require approximately 
10db more margin than is needed for 


1200bps AFSK. For example, if a link 
works okay at 1200bps with low-gain 
omni antennas at each end, then re- 
placement of the antennas with small 
yagis should provide sufficient margin 
for upgrading to 56Kbps (assuming the 
same power levels). 

There are a number of reasons that 
the Ottawa working group has a strong 
preference for using the WA4DSY 
56Kbps modem in linking projects. 
After working with the modem for 
nearly 3 years, we have a good deal of 
experience with it, and a high degree 
of confidence in its capabilities and 
reliability. It offers much higher value 
in terms of bits per second per dollar 
of investment than the lower speed 
modems, and its higher throughput 
means a longer lifetime before obso- 
lescence. It is very easy to deploy, 
since it is a self contained RF modem 
which does not have to be interfaced 
to standard radios - its 28Mhz IF is 
simply converted to VHF/UHF using 
a standard transverter (or separate 
receive and transmit converters, in the 
case of full duplex). And it will run full 
duplex with no difficulty, unlike some 
lower speed modems. 

The use of speeds of 56Kbps or more 
necessitates the upgrading of nodes 
with more capable packet switch 
hardware than the TNC2. Like the 
Ottawa Hydra switch, a multiport 
node can be configured fairly inexpen- 
sively around a PC AT class machine. 
The TNCs can be retained to handle 
the low speed nodes. For major node 
sites with multiple 56Kbps (or higher 
speed) ports, a more attractive propo- 
sition is the Grace PackeTen packet 
switch board. The latter board can 
make use of a PC as a host, so again 
there is a clear upgrade path if a PC 
is used for the switch. 

—VE3JF, Barry McLarnon 

[Editor's note: VE3JF is not a 
NEDA member and probably has not 
read the club literature. My personal 
belief is that the NOS switches that 
Barry is suggesting as node sites are 
indeed the way of the future. See the 
TCP/IP article on the front page. 
Grace makes a stand-alone version of 
the PackeTen which is capable of han- 
dling the rougher environments and 
will run NOS without the PC. For the 
moment NOS switches are not accepted 
by NEDA for use as NEDA network 
hardware. I would also not like to 
discourage someone from putting up a 

Continued on next page —> 
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Saratoga Network 
Gateway On Line 


The linkup between the NEDA net- 
work and the Saratoga County RACES 
packet network is now in place and 
operational. Cooperating in the effort 
to get the link in place were Jim 
WA2UMH and Dana WA2WNI. 

The link connects the SRTGA1 node 
in Lake Nancy NY with the ALBANY 
node in West Grafton N.Y. via a low 
power directional UHF circuit in the 
433 MHz range. The port on the 
NEDA side of the Gateway at the AL- 
BANY site is ALBNY3. To use the 
gateway going north: connect to 
ALBNY3 and then connect to 
SRTOGA. To use the gateway going 
south: connect to SRTOGA, then to 
NEDALB. 

This single stepping routine and 
configuration is what protects each 
side of the link from ingress of data or 
broadcasts from the other system that 
could potentially upset each system’s 
operational characteristics. 

BBS ops in the NEDA side of the 
system may use this circuit to reach 
WA2UMxX BBS which is reachable as 
a directly connectable mnemonic from 
the SRTOGA end of the link. 

Difficulties in traversing the link 
should be reported to WA2WNI @ 
WA2PVV should they occur. The pre- 
vious WMA220 to WA2UMX-12 is 
presently not operational and may also 
be decommissioned due to the loss of 
the lower end of the 220 band to ham 
use. 

An alternate to pass traffic headed 
for WA2UMxX is to forward it to 
WA2PVV if sent from the east or 
WA2TVE if sent from the west or if the 
network fails W2RGI. W2RGI and 
WA2PVV have backup 145.01 paths to 
WA2UMX. 

—WA2WNI 
—Eastern NY NRS 


Ottawa continued from page 4 


node just because it can't be upgraded 
to high speed. I don't think that Barry 
meant that either! 

Board members of NEDA have 
made strong statements in regards to 
packet radio connections to the Internet 
and there are many technical implica- 
tions that must be worked out in order 
for such a gateway to be legal. 

Thank you very much for this con- 
tribution Barry and hats off to the Ot- 
tawa crew for an excellent city-wide 
network!] 


Software Wanted! 


NEDA is in need of a handful of 
software utilities to help diagnose, 
troubleshoot and configure network 
nodes and links. Specifically what is 
needed is programs that can be run on 
an IBM PC/XT/AT or compatible com- 
puter that will allow a node sysop to 
poll or interrogate a node and make 
changes to that node quickly and effi- 
ciently to keep network operation up 
to snuff. Currently, when a node 
sysop needs to make changes, the node 
must first be checked for operation, 
then put into "sysop mode" and then 
the changes made. All of this is pres- 
ently done via manual lookup tables 
and comparing past or present values 
with those changes that need to be 
made. Discrepancies in parms, or 
specific port characteristics of interest 
must be manually noted or logged by 
the sysop, then reviewed or compiled 
later to figure out what is going on or 
if changes have been effective. This 
can be very tedious and requires that 
NRSs (Network Regional Sysops) have 
a very good memory of what is going 
on and what changes have been made 
and they must be rigorous and com- 
plete in their notes.. 

Ihave several ideas of good software 
projects which desperately need doing. 
There are many other ideas floating 
around as well. I am willing to offer 
technical support, encouragement and 
a dozen test sites. I will also see to it 
that the program author gets full rec- 
ognition for the effort, and the program 
made available world wide to help with 
network management. The program 
will be released into the public domain 
with full credit to the author. Sources 
and data files will be released as well. 
Your callsign becomes a household 
word for hundreds, if not thousands of 
hams who operate nodes. Everyone 
who submits a program will get men- 
tion in the NEDA Quarterly. 
KA2DEW has volunteered to create 
documentation to support your efforts 
if you like. 

Here's what I am looking for. Re- 
member that these are general ideas 
for your program and not absolutes. 

In order to complete some aspects 
of these projects you'll need some sup- 
port from your local NRS. As it is the 
NRSs that will benefit most from these 
programs you can be sure of getting 
exceptional support. This is a real 


Continued on page 6 


Regional Technical 
Development Meeting: 
Scranton Pa. 


On April 6th a technical develop- 
ment meeting was held in Scranton 
Pa. The following NEDA members 
attended: 


WB2QBQ Bob Seger 
WA2VAM Kevin Wright 
KA2DEW Tadd Torborg 
WA2WNI Dana Jonas 
KA30DJ Andy Horn 
N2CZL Don Russ 
NX2P Bill Slack 
NONDO John Painter 
WB3LWR Bob Chimel 
KC4ZWI1 Pete Presti 


Talk was had about putting up 
nodes in the Scranton area to link 
Binghamton or Elmira to BANGOR 
via Scranton. Presentations were 
made on TCP, DxClusters, PBBSs, 
ROSE and TheNET. 

The person who did the TCP pre- 
sentation KB3YV stated that his goal 
was to get a LAN up so that local users 
could access Internet via packet radio. 
High speed is desirable and long dis- 
tance amateur packet networking is 
not necessary as Internet provides 
world wide networking. 

The person who did the DxCluster 
presentation stated that he wanted a 
DxCluster-only network to support the 
DxCluster activity and that the way to 
handle large volumes of users was to 
use as many 2m channels as necessary 
with wide coverage 2m access to Dx- 
Clusters. Cooperation with a general 
purpose network group was not nec- 
essary or beneficial and no attention 
to the scarcity of 2m channels was 
given. 

The BBS presentation was by 
K3RLI who gave a lengthy presenta- 
tion on the FCC vs packet controversy. 
Ed (RLI) didn’t promote or demote the 
cause of general purpose networking 
and is not planning on helping the 
cause. 

The ROSE presentation was by 
NX2P who is very much in favor of 
doing long distance networking using 
all of the NEDA philosophy but limited 
to ROSE node implementation. Bill 
(NX2P) says he will be working with 
WA2WNI and others to link up a 
budding ROSE system in NJ and Or- 
ange County NY to NEDA nodes in 
eastern NY. 


Continued on page 6 
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New Deal Available on 


UHF HTs 


About a year or so ago some NEDA 
member may recall how we were 
frantically buying up Wilson MH-400 
UHF HT’s that we then put into links 
in a number of places. WA1TPP did 
an article for the Quarterly that 
showed us how to speed up and utilize 
the rig for packet as efficiently as pos- 
sible and thus a number of links and 
special ports were put on the air as a 
result of these inexpensive little 2 watt 
hand held rigs. (The rigs only cost us 
about $80 each!) 

Well, it appears that the original 
vendor has struck yet another bargain 
with the folks at the Wilson/Regency 
warehouse and managed to make an- 
other incredible bulk buyout. The deal 
this time is for UHF Regency MCPU- 
404 handhelds. These rigs are new 
closeouts that are 4 channel, 4 watt 
crystal controlled handie talkies. 
While they don't come with antennas 
or batteries, the vendor is selling them 
to us for the incredible price of $49.95 
each plus shipping. If you should 
choose to use the rig as a portable and 
not canabalize it for a packet link the 
vendor will sell you a drop in charger 
for $29.95 and batteries for $20 each. 
The batteries, bye the way, are the 
same ones used by the Yaesu FT 203 
and 209 series radios, known com- 


Scranton from page 5 


The TheNET presentation was done 
by KA2DEW who promoted the same 
thing that NX2P was promoting and 
offered that TheNET was more fun to 
play with than ROSE. 

It was an interesting meeting. 
Dinner afterwards was, as is tradi- 
tional it seems, held at a Pizza Hut. 
Conversation after the meeting, at the 
meeting site and at dinner was lively 
and positive. My impression is that 
there are some people in the Scranton, 
Wilkes-Barre area that are very anx- 
ious to get hooked up. 

Dana, Bob, Pete and I finally ar- 
rived back at KNOX node (Bob’s house) 
at about 1:00 AM. 


mercially as a BP-4. The crystals it 
takes are HC-18u size with wire leads 
and the unit also has a factory in- 
stalled jack that will take a plug in 
CTCSS board. 

Please contact the vendor directly as 
we will not have sufficient time to put 
together a NEDA bulk buy like in the 
past. He was kind enough to let us in 
on the lower pricing because of being 
on his preferred buyers list from the 
previous 30 or 40 odd units we bought 
before. Please move quickly on this as 
the vendor might do something like 
raise the price or sell the whole lot to 
someone. The address: 

Torg's Electronics 


9280 W. 360N 
Shipshewana, IN 46565 
Phone: (219) 768-4406 


The proprietor is Mr. Torgeson so 
should you give him a call to get in on 
this, make sure to pass on the regards 
and best wishes for all the NEDA 
members already taking advantage of 
the bargains he has provided us in the 
past. Who knows? With a little effort 
maybe we can get Mr. Torgeson to get 
his own ham license!?! 

Oh, one more thing....Manuals for 
the unit should be readily available 
from Regency Electronics, or Torg’s can 
most likely provide you with a copy for 
a nominal extra cost. 

—Dana WA2WNI 
—KNDRHK & ALBANY node op 


Software from page 5 


good way to get directly involved with 
the NEDA technical committee. 
Please contact me via packet at 
WA2WNI @ WA2PVV or connect to my 
home station WA2WNI from the 
DANA node at the KNDRHK node. 
(Connect to KNDRHK and then con- 
nect to DANA and then connect to 
WA2WNYD) You can also leave mail for 
me directly on my PMS, WA2WNI-4 
from the DANA node. 
List of features for all programs: 
¢ The program must be able to run on 
an IBM XT or AT or compatible 
computer and not require more 
than 640K RAM and 1 floppy disk. 
e The program must work without 
graphics although graphics support 
is OK as an option. 
¢ The program should use an RS-232 
port to send/receive data to/from a 
TNC2 compatible TNC such as a 
PacComm Tiny-2 or MFJ 1270B or 
equivalent Terminal Node Control- 
ler. G8BPQ compatible would be 


great but is not necessary. 
¢ Program may be written in C, 
PASCAL, 8088 assembler, BASIC 
or Turbo BASIC 
Here are two ideas for utilities that 
all of the NRSs in the NEDA network 
and most other TheNET node ops on 
the continent could utilize. 


Automatic Node Manager 

This application is intended to re- 
lease a sysop from the tedium of con- 
necting to a given node, checking its 
nodes list, routes, parms, ident and 
then making any changes that are 
needed after using the Sysop Password 
to gain remote control of the node. 

¢ User enters node name. Program 
accesses disk and finds connect path 
info and node password string. This 
info must be stored in text format so 
that it can be edited with IBM PRO 
editor, Norton Text Editor, SEE, Brief 
or some other simple text editor. 

¢ The program can connect thru the 
network to the requested node via the 
path specified on disk. 

¢ The program should read and 
save the nodes list, routes list, parms, 
info string, users top line and bad 
command message. This should be 
viewable from in your program. 

¢ The program can send the sysop 
code and answer the password string. 
A flag should be set in the program to 
remember that the sysop operation has 
been done. If it has not been done then 
it should be done whenever the user 
tries to perform a function that re- 
quires the sysop privilege. 

e The program can receive the 
parms dump and by interrogating the 
USERS command response can ana- 
lyze the parm dump depending on the 
TheNET software. A menu is pre- 
sented that shows the parm meanings, 
current values, stored prepared values 
from the node's file, and NEDA rec- 
ommended values for this type of node 
(bkbn, gateway, user). Differences 
would be highlighted. By pressing a 
few number keys or by using cursor 
control the user should be able to select 
parm values to change and then when 
done with changes should be able to 
send all changes. 

¢ An info text editor should be able 
to receive the existing info text, edit it 
and then put it back. The program 
figures out what the node software 
version is via the USERS command 
response and then presents the user 


Continued on page 7 
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with an editing page that shows num- 
ber of bytes used, left and shows the 
text as it is being edited. Because v1.1 
TheNET only allowed 80 characters to 
be changed while TN2.08 allows 160 
the program has to be pretty smart. 
The v1.1 version should show the fixed 
part of the info text as well but not al- 
low it to be changed. 

¢ The user should be able to load 
parms from the file on this node. The 
desired parms should be saved in a 
separate area in the file than the ac- 
tual parms. A feature should exist 
that copies the actual parms into the 
desired parms area. 

¢ The program can ask the node for 
all three routes to all of the nodes that 
are returns with the NODE * com- 
mand. The list can then be correlated 
with the ROUTES command to show 
all nodes sourced from all neighbor 
nodes. 

¢ Response time for each message 
sent should be obtained and displayed 
on the screen along with the current 
date and time. 

¢ The user should be prompted for 
a text string asking what changes are 
needed and why. This text plus sysop 
commands sent, average response time 
and date sysopped should be recorded 
in a append area in the file. 

¢ An abort procedure function must 
exist so the user can dump out of any 
operation. 


Network Diagnostic Package 

This software package is intended 
to give sysops some assistance in 
evaluating various characteristics of 
operation and node statistics. Pres- 
ently the various regional sysops spend 
a great deal of time trying to keep up 
with how things are working. It is 
their job to try to keep the traffic 
flowing, and make sure that all view- 
able nodes that show on node lists are 
connectable. Outages that cannot be 
cured or temporarily bypassed need to 
be promptly reported to not only those 
responsible for maintenance, but vari- 
ous users (such as PBBSs) that depend 
on up to date information on appro- 
priate routing and throughput effi- 
ciencies. 

This program is very similar to an 
older program called "Net Walker". 
The basics of the program are that it 
connects into the network as specified 
in it's configuration file on disk. It does 
a nodes list on the local node and then 


attempts to connect to every node on 
the nodes list. If it runs into a BBS it 
waits for the > prompt and then dis- 
connects. For each node that it con- 
nects to it performs a Routes com- 
mand. Any callsigns that it sees on the 
routes command that it doesn't have 
already it will try to connect to. To do 
this it will have to disconnect each time 
and connect back out. Some nodes 
cannot be connected from. At each 
node it should acquire the info text, 
parms, and routes. 
After the program runs out of nodes 
to connect to or after it is aborted it 
should generate five documents: 
¢ A list of nodes sorted by distance 
from start. 
¢ A list of nodes sorted by suffix of 
callsign. 

¢ Alist of nodes sorted by node name. 

¢ A complete record of all info texts, 
parms and routes and average re- 
sponse time should be printed for 
each node sorted by node cluster 
sorted by node name. A node clus- 
ter is how ever many nodes are 
connected together by RS-232 

routes (port 1). 
¢ A list of node, route and parm 

changes. 

The program should be configurable 
to run automatically at a preset time. 

Optional features: An ASCII file 
analysis routine to "munch" the data 
collected by the Diagnostics and then 
issue a report. This could work much 
like the present WORLI PBBS monthly 
statistics routines do. Desired data 
would be nodes lists comparisons, node 
reliability, path reliability, parm 
changes, new info texts, routes lists 
comparisons or flagging of new routes 
recognized. 


Conclusion 

So there you go. Here's a good start 
on what we need to help with network 
management. This seems like the kind 
of project that could be done by stu- 
dents or a group of students. Any 
professors/teachers out there? 

My address is: 

WA2WNI - Dana Jonas 

RD. #2 Box 92 

Valatie, New York 12184 

If you have questions about the ap- 
plications or merely wish to make 
comments about what you think might 
be usable ideas for the participants of 
the project, please feel free to contact 
me. 
—Dana WA2WNI 
—NEDA NRS, Eastern NY 


TCP/IP from page 1 


computer to another over any number 
of intermediate computers. Unlike 
FTP and TELNET which require that 
an end to end path must be established 
in real time SMTP allows messages to 
traverse the computers that are avail- 
able and then wait for computers that 
are unavailable and then proceed 
when they come on line. 

FINGER is a command whereby a 
user can ask a remote machine for in- 
formation about another user. Thus I 
could do a finger on the user NQ1C on 
the machine NQIC and get back that 
NQIC is Bob Lafleur and whatever 
other information that Bob wants his 
finger file to contain. 

PING is command to send a packet 
to a remote computer to find out if it 
is connected to the network and if so 
how long it takes to get a packet there 
and back. 

There are many other useful proto- 
cols built into TCP/IP that allow such 
things as data sharing between pro- 
grams running on two different com- 
puters, identifying what hosts are 
available, finding out the time at a re- 
mote machine, authenticating pass- 
words and even passing silly quotes. 

Message routing with TCP/IP is 
based on a 32 bit address and aliasing. 
Each host computer is given it’s own 
specific 32 bit network address and a 
text alias. The text alias for amateur 
TCP/IP is usually callsign.ampr.org. 
The .ampr.org is used to differentiate 
the amateur network with the com- 
mercial networks in cases where there 
are tie ins between the two. The 32 
bit address if of the form 
255.255.255.255 where each of the 
numbers is called an octet signifying 
that it uses 8 bits. Each of the four 
octets from left to right decreases in 
priority. The first octet is used to de- 
termine whether the destination ad- 
dress is ham, military, commercial, 
educational, etc.. The second octet 
might indicated which state the desti- 
nation machine is in. The third, de- 
pending on how the ham TCP/IP ad- 
dressing committee decides to run 
things, might determine a network 
node output or a county or city. The 
last octet determines which individual 
machine that the message goes to. So, 
given that the network extends across 
the country, it should be possible to 
address a message from any TCP 
computer to any other. The address- 

Continued on page 8 
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ing system also allows for more than 
one user at each machine. Thus I can 
be ka2dew@k1tr.ampr.org which is 
different than k1tr@k1tr.ampr.org. 

The process in the TCP program 
which sends messages from the host 
and waits for acknowledgment from 
the destination station is more so- 
phisticated than TheNET. With 
TheNET up to four messages are sent 
out of the originating node and then 
when acknowledgments come back for 
those messages new messages can be 
sent out again. Four messages may be 
outstanding at a given time. If an ac- 
knowledgment for a message doesn't 
come back for 5 minutes the originat- 
ing node will regenerate the message. 
With TCP/IP what is a 5 minute timer 
in TheNET is automatically adjusted 
depending on previous performance of 
the link. This is called ‘backoff. TCP/ 
IP is loaded with this kind of intelli- 
gent networking features. 

TCP/IP using the KA9Q software 
package is very easy to modify. 
NET.EXE which is the original KA9Q 
package has been added to by dozens 
of other amateurs. NOS, Network 
Operating System, is updated and 
customized by many hams for many 
purposes and is entirely public domain. 
This is in contrast to TheNET which 
is only modifiable with great difficulty. 

TCP/IP is a mature protocol system 
due to the vast number of people 
working with it. TCP software is 
available for most computers. It can 
be run over a huge number of differ- 
ent kinds of data links. It is extremely 
powerful. It is in use on many, if not 
most, commercial workstation systems 
in the world. Sun Microsystems, 
Apollo, HP, Xerox, DEC, Apple, Next, 


Wang, and most other computer com- 
panies either use TCP/IP exclusively 
or at least offer support for it as a 
standard feature of their computers. 
Why Aren't All Packeteers Using 
It? 

The first reason is that it won't run 
in a simple TNC. It is quite possible 
to have lots of fun and take advantage 
of many of packet radio's capabilities 
without TCP/IP. Truly there are 
things that we can do with TCP/IP 
that we can't do without TCP/IP. 
Many things we're already doing 
without TCP/IP could be done better 
with TCP/IP. That won't convince all 
packeteers to use TCP/IP from their 
homes. At this time TCP/IP still re- 
quires a computer somewhat more 
powerful than a TNC, 

The NEDA network currently 
doesn't allow access to TCP/IP users. 
The reason is that TCP stations are 
themselves networking hosts. They 
can source high volumes of data to the 
network at will and can be remotely 
controlled from other TCP stations to 
do this. In order to function across the 
network TCP switches, by there very 
nature, must be independent of the 
controls that TheNET places on net- 
work traffic through the TheNET pa- 
rameter controls. Specifically, retry 
rate and window size are controlled for 
NEDA AX.25 users but couldn't be 
controlled for TCP/IP users. In addi- 
tion the NEDA network user access 
policy is designed to permit equal ac- 
cess to network services by all stations. 
Because of the way packet works in 
regards to hidden transmitter syn- 
drome, stations transmitting into a 
user port cause much more loading 
than stations receiving from a user 
port so having TCP/IP stations on 


shared 2m channels would not be fair. 
The way that NEDA is currently 
planning on interfacing TCP/IP to the 
network is that selected TCP/IP hosts 
would gateway into the network via 
hidden transmitter free links on 220, 
440 and up. Those gateway hosts will 
be operated in accordance with NEDA 
technical committee specifications. 
(Hopefully the number of TCPers on 
the technical committee will take a 
giant leap in the near future!) Other 
TCP stations would then access the 
network via the gateway TCP host. 

Beyond that in the more distant 
future there would be NEDA nodes 
that are based on NOS (Net operating 
system) which is a program that sup- 
ports TCP/IP and TheNET. One or 
more ports on the NOS node would 
then be available for TCP access to the 
network. An intriguing capability of 
NOS is the ability for a TNC-only user 
to connect into the NOS node and then 
use it's TCP features. 
For now 

For now the NEDA Board of Direc- 
tors has declared that only WZ2B and 
NQIC will operate as TCP gateways 
into the NEDA network. This is for a 
trial period until they have had time 
to analyze the effectiveness and prob- 
lems with TCP across the NEDA 
TheNET network. They will then re- 
port their results at a NEDA board 
meeting. Stay tuned to this column for 
more information on the subject or 
contact NQ1C or WZ2B. If you are 
interested in participating in the 
NEDA technical committee please 
contact Rich, WB2JLR @ WB2WXQ. 
Rich is the chairman of the NEDA 
technical committee. 
—KA2DEW 
—NEDA editor 


Active Coupler for Mating A GSBPQ PC to a Hexipus TheNET/Diode Matrix 


Quite a few of the switching systems 
in use today on the NEDA network 
feature not only a multiport node but 
also a PC-based BBS or mailbox. The 
node setup on most of these systems 
involves the use of a diode matrix to 
allow all the TNCs to transmit and 
receive data harmoniously with one 
another. And, most of these diode 
matrices are in the form of a small 
circuit card (like NEDA's HexiPus) 
which holds the various passive com- 
ponents. Because these sites are often 
in key locations, the SYSOP can, and 
often does, opt to incorporate a BBS or 
mailbox to compliment his/her setup. 
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These BBS/mailbox incorporations 
also include in background implemen- 
tations of John Wiseman's outstanding 
network software packet (hitherto re- 
ferred to as "BPQ") to allow for mul- 
tiple connects into and out of the 
mailbox software. BPQ's original in- 
tent was to provide an easy way for 
hams to create packet data switches 
using their already existing IBM or 
compatible computers. A serious 
drawback exists because should the 
computer crash for whatever reason, 
the switch code itself dies until the 
computer is reset. To be effective for 
a large multiport node setup, BPQ of- 


ten requires a very fast (and very ex- 
pensive) computer to handle the many 
streams of data. 

A very real advantage of using the 
diode matrix card in conjunction with 
the BBS/mailbox combination is that 
the matrix never "dies" allowing the 
node to stay active even when the PC's 
hardware or operating system fails or 
is taken off the air for whatever rea- 
son. 

BPQ code though was thought im- 
possible to add direct to this diode 
matrix. The signals just weren't com- 
patible. To get around this and the 

Continued on next page 
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more important limitation mentioned 
above, NEDA devised a scheme 
whereby placing two TNCs "front-to- 
front" would allow for the node to exist 
on one side and the BBS/Mailbox to 
exist independently on the other. By 
facing these TNC’s HDLC (radio) ports 
toward each other, the RS-232 ports 
became usable - one looking toward the 
matrix and one toward the BPQ code 
and the associated BBS/mailbox. 

As this idea developed, we pro- 
gressed from simply cross wiring the 
Tx/Rx lines off of the DIN connectors 
to picking the digital Tx/Rx signals off 
of the modem disconnect headers in- 
side the TNCs. This allowed us to set 
the baud rate of that link up to 19200 
baud. 

Two advantages were apparent. 
First, the computer could crash all it 
wanted but the node stayed a viable, 
active part of the network. Second, the 
computer now was not burdened with 


the awesome task of switching data 
between its serial ports plus doing the 
work on the BBS. However, this in- 
volved the use of two TNCs - a couple 
of hundred bucks just to do this? Boy, 
was this expensive! There must be a 
better way. 

Enter yours truly. I had a spare 
older XT and a temporary allocation of 
TNCs connected to the matrix to play 
with and besides, I had an afternoon 
to kill. 

I reasoned that since BPQ code was 
basically simulating a TNC-like device, 
why couldn't it be directly connected. 
I quickly drummed up a working ver- 
sion of the BPQ code and configured 
one TNC (with TheNET 1.16) as a 
node via the matrix card. Asa start, I 
just tied the various lines off of a va- 
cant port of the matrix to match the 
RS-232 lines on the PC's serial port. 
Needless to say it didn't work. So I 
started taking things off and rear- 
ranging them. When I took the RX 


IBM PC Serial to Hexipus 


PC connector 


Active Adapter 


Hexipus connector 


TxData > _—_—_——————— RxData pin 2 
RxData @———  —__———————F* TxData pin 3 


10KQ 


RTS 


GND 


DCD 


DTR 


CTS pin 8 


GND pin 5 
DTR pin 7 


NEDA node with server 
connected using a wireline link. 


NEDA node with server 
connected using the 'Active 


Adapter' 


and TX data lines and reversed them, 
it started working! After a brief period 
of testing, I published my findings to 
NEDA @ WINY and got some enthu- 
siastic bravos. 

Rich Place, WB2JLR made one im- 
portant addition however which I 
didn't account for. The DCD circuit 
was doomed to fail in that my little 
"experiment" didn't incorporate more 
than one TNC. Rich was certain that 
placing the PC on the matrix with 
more than one TNC would cause 
problems without correctly using the 
DCD/CTS collision detection scheme. 
He drew up a simple way to use the 
DCD circuitry between the PC and the 
matrix using two 2N2222 transistors 
and some pull-up resistors. This circuit 
inverts the states of the DCD and CTS 
lines from the PC, making them work 
with the DCD and CTS from the TNC 
2s. 

Since implementing this, I have re- 
gained two shiny new TNCs for use 
elsewhere, reduced the load on my 12V 
DC power supply by 2 TNCs and 
eliminated a source of traffic delay be- 
tween my BBS and the rest of the net- 
work. (Someone recently pointed out 
that they had noticed an overall im- 
provement in the speediness of the 
return data). As an extra added bo- 
nus, by setting the BPQ code up with 
certain parameters turned on, I get to 
see all the L3 and L4 activity between 
the BBS and it's users as well as all 
internode traffic and TheNET activity 
between the TNCs on the matrix, 
something I was unable to do previ- 
ously. One down side of this method 
is that I lose my "Mail For:" beacon 
(who cares!). 

My thanks go to Rich WB2JLR and 
Mike N1BEE for their help and en- 
couragement. Special thanks to Tadd 
KA2DEW and Rob KC3BQ for the 
original thoughts and work on getting 
this system off the ground. 
—WBIDSW, Herb 
—KNGSTN node op 
BBSDSW/NEgate BBS sysop 
New England's longest running 
packet radio mailbox 
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THIS DIAGRAM SHOWS ONLY THE REGIONAL 
NETWORK, IT'S CONNECTIONS TO NEIGHBOURING 
NETWORKS ARE INTENTIONALLY OMITTED TO 
SIMPLIFY THE ILLUSTRATION. 
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AVOISINANT SONT OMIT POUR SIMPLIFIE LE 
MODELE. 
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Photographs from Spring Board Meeting 


Board Member Linds Collins NRIN 


During a break Cal and Cal are showing Dana (just out of the picture on the left) the packet map they've put together. 
In the picture are, from left to right, Cal W1JFP, Rus WA1TLN, Chan KA10U and Cal WA1WOK. 
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Board Members Cal Stiles W1JFP on the left and Dana Jonas WA2WNI on the right. Rich Place WB2JLR standing up 
is opening the meeting as chairman. 


Board Members Kevin Wright WA2VAM on the left and Jim Wzorek K1MEA on the right. 
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For version 2.08B 

March 1990 

Programming: Bill Beech, NJ7P 
Documentation: 


Jack Taylor N700 

DanaJonas © WA2WNI 

Tadd Torborg KA2DEW 
Edited by KA2DEW 


The following documentation is a 
product of several hams. N7OO origi- 
nally documented the TheNET Plus 
product by NJ7P. WA2WNI and 
KA2DEW, both NEDA members, ed- 
ited the N700 document to produce 
the Resource Manual in March 1991. 
Later KA2DEW did major modifica- 
tions to the document, adding the 
Theory of Operations section and the 
Common Problems section as well as 
many paragraphs in all of the remain- 
ing sections. This document is first 
released in the Spring NEDA Quar- 
terly of 1991 (v2.2). 

The following provides an excellent 
overview of Networking and nodes as 
known by the amateur community 
presently experimenting with TheNET 
nodes. It is important to remember 
however that many nodes outside the 
NEDA network are implemented 
without a specific plan of participation 
in a controlled, Hidden Transmitter 
Free backbone connected multi-service 
network. The hidden transmitter free 
dedicated link backbone is in essence 
the key element to the NEDA system. 


Forward 
For a long time there has been a 
need for a practical NodeOp manual. 
While the material presented herein is 
primarily for those desiring to set up 
and operate a TheNET Plus node, the 
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methodology and procedures should 
apply to the operation of any of the 
netnodes. There are bound to be ar- 
eas lightly covered, or overlooked. No 
doubt others will have differing opin- 
ions on some topics. Our goal here is 
to provide detailed and factual infor- 
mation on the art of NodeOping. 


TheNET Plus Versions 

v2.00 was the prototype test node. 
The maximum number of calls listed 
in the Heard list was 10 over a 10 
minute period. 

v2.01 was the first “official release 
of TheNET Plus. The Heard list was 
changed to a maximum of 20 calls 
listed over a 15 minute period. A pa- 
rameter was added which allowed the 
NodeOp to set the maximum number 
in the Heard list to a value less than 
20, if desired. 

v2.02 was not released. 

v2.03 was identical to v2.01 with 
the exception of a bug fix associated 
with Parameter 24. In v2.01 if callsign 
verification was turned off, it also dis- 
abled the N * function. v2.03 corrects 
this situation. 

v2.04 corrected a problem caused by 
the fix in version 2.03 and changed 
Parameters 28, 29, and 30 to agree 
with the SETPLUS utility and this 
document. 

v2.05 added several new NodeOp 
convenience features. One was to have 
the STA LED light when someone 
connected to the node. It was felt this 
would assist the NodeOp in servicing 
his equipment while at the site. An- 
other new feature was to add three 
sysop KEY commands, MARK, SPACE 
and DIDDLE which keys the trans- 


mitter and turns on appropriate 
alignment tones. Also added was an 
ON - OFF remote control capability. 
One of the NODE command responses 
was changed to Host busy, instead of 
Host table full when a user at- 
tempted to connect to the host (a non- 
allowable function when the host port 
is active). The Not Found response to 
an unknown node now indicates Not 
Found: <node alias> to assist those 
running multiple streams in identify- 
ing which stream is which. 

v2.06 corrects a long standing 
routing display anomaly, which takes 
care of the last known problem. 

v2.07 was not released. 

v2.08 adds connect command dis- 
able, #node propagate disable option, 
adds broadcast via port options and 
reorders parm list. 

v2.08B makes ROUTES command 
response show both mnemonic and 
callsign. 
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Background 

NORD><LINK in Germany created TheNET with the 
first release called TheNET Version 1.0. Equipped with 
the user friendly INFO feature it has become very popular 
with node ops around the world. With their distributions, 
NORD><LINK provided source code in the public domain 
so other programmers could do node development work. 

TheNET Plus (here after called TheNET) came about 
after observing that the retention rate of packet newcom- 
ers was very low. One of the factors discouraging the new- 
comers was that they didn’t know who to talk to out on the 
network. After considerable effort, NJ7P was able to modify 
the original TheNET code so the node would list users in a 
heard list. Further development led to some additional user 
features and thus, TheNET Plus was born! 

This manual is intended to provide a practical guide for 
the new, as well as the seasoned NodeOp in setting up and 
operating his TheNET Plus node. 


Version 2.08B Highlights 
TN2.08B has the following features over those found in 
NORD><LINK's TheNET version 1.0: 
e Aliases have been added to callsigns in the ROUTES list. 
¢ Not found <aliascall> response to an unknown node 
(instead of a nodes dump). 
(B)ye command added. 
(H)eard command added. 
INFO section completely sysop programmable. 
TXD is remotely sysop programmable. 
STA LED lights when a user connects to the node. 
ON - OFF remote control feature added. 
. Sysop KEY commands allow keying node radio with 
mark, space, or diddle alignment tones. 
e¢ L2 and L3 callsign lockout feature for network adminis- 
tration. ) 
e PARM string shortened to 16 parameter entries. 
¢ A Parameter has been added to allow/disallow node 
broadcasts on either the RS-232 or modem (radio) ports. 
¢ A Parameter has been added to allow/disallow the 
propagation of the # (hidden) nodes. 
¢ A Parameter has been added to allow/disallow CON- 
NECT commands. 


Theory of Operation 

TheNET is a software package that runsin a TNC2. The 
purpose of the software is to control a TNC in a system of 
TNCs called a network. The network is usable by hams 
running any mode of amateur radio packet based on AX.25 
protocol. The hams can utilize the network to chat in real 
time, access remote computers, pass traffic or perform 
paging and remote control. Follows is a technical descrip- 
tion of the TheNET software. 


Hardware - L1 

The TNC2 is a dual port device. That is, it has two se- 
rial i/o channels. One of these i/o channels is hooked to an 
RS-232 driver and a D shell connector. The other i/o chan- 
nel runs to the modem disconnect header and then to a 1200 
baud modem. 

The software that runs in the TNC2 is installedin a 32K 
EPROM and is mostly compiled C code. Some small sec- 
tions are written in assembly language. Also stored in the 


EPROM are default parameters and text strings. Gener- 
ally the text strings are not user programmable but a bit 
hacker could find them and change them. Text strings that 
exist include "Connected to" message, command names, 
"USERS" response string, beacon text and error messages. 
The default parameters, callsign, node name and password 
are programmable. Most installers of TheNET Plus 2.08B 
will be using the SET208.EXE program with a PC. 


International Systems Organization (ISO) 

The function of a TheNET node is to act as an active 
data store and forward device as well as a remote command 
interpreter for users. Communications can occur both on 
the modem port and on the RS-232 port at the same time. 
Communications is AX.25 with networking and routing 
operations which are written within the bounds of the ISO 
7 level model. That is that the processes in the TheNET 
software are modularized in the following functions: 

L1:I/O control and hardware; 

L2:AX.25 linking; 

L3:network routing; 

[4:transport processor; and 

L7:command processing. 


Link Controller - L2 

The TheNET node's link controller will accept and make 
AX.25 connects on either the modem or RS-232 ports. Ifa 
station connects to the TheNET node on either port the node 
will remember that a connection is made, the callsign of 
the connecting station, and the callsign that was used to 
connect to the node. These are saved as the address field. 
The node can accept the connect using the preset callsign 
and ssid in the EPROM or using the nodename with any of 
16 ssids. Connects may be accepted by the node from the 
same callsign on all 17 callsign - nodename - ssid combina- 
tions at the same time. The next time a packet is received 
that matches that address field the node will classify the 
connecting station as either a user or as another node. 

If the connection is a user then the user is added to the 
users list and any further communications is passed to the 
command processor. The user may interrogate the node 
for information that it has (see user commands) or he may 
command the node using the sysop commands or using 
CONNECT or CQ. If the user uses the CONNECT com- 
mand he may establish a connection to another node or to 
a user from this node. This is covered later under "Circuit". 


Routing Processor - L3 

If the connection is another node then the next message 
that follows will contain TheNETese. TheNETese is a slang 
term that means that the communications has non print- 
able characters that TheNETs understand. More on that 
will be covered under Protocol. If the node's link controller 
gets the TheNETese then it marks the station as a neigh- 
bor TheNET node and passes the connection information 
up to the routing controller. If the traffic that is received 
is destined to another node then the routing processor 
passes it back to the link controller to go out to the next 
neighbor node in the chain. A neighbor node is a node that 
this node can talk to directly, either over the RS-232 port 
or over the modem port. 
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Transport Processor - L4 

If a neighbor node passes traffic to this node that is des- 
tined for this node then the routing processor passes the 
message to the transport processor. The transport proces- 
sor is responsible for making sure that all data that origi- 
nates at this node or is destined to this node makes its way 
across the entire path between circuited nodes. So, if I 
connect from this node to another node that is many sites 
away it is the transport processor that is responsible for 
seeing that the message gets there. 

The transport processor gets messages from the network 
processor and from the command processor. The command 
processor is hooked to the user. Users can connect to a node 
and then tell it's command processor to connect to another 
node. Users can tell the command processor to connect to 
another user or server station. 


Command Processor - L7 

The command processor may be instructed with ASCII 
text commands from a user station. Much of the remain- 
der of this manual deals with command processor func- 
tionality. The important functions needed for understand- 
ing of the remainder of "Theory of Operations" is that the 
command processor allows the user to connect to other 
nodes via the network over either the modem port or the 
RS-232 port and to stations that are not nodes over the 
modem port. In addition the user can request lists of: 

all nodes in the routing table; 

neighbor nodes; 

the best three neighbor nodes for a particular node; 

all L2 connected stations known to be users. 


Program Start-up 

The program starts up when power is applied. It lights 
the STA and CON LEDs for a second and then turns them 
off. It initializes its memory, copying default parameters 
unless it has what it things are valid parameters and INFO 
message in RAM already. Then it sends a beacon message 
on both the modem and RS-232 ports. The node broadcast 
timer is started. 


Routing 

When the routing processor gets a packet to send out it 
looks at the destination address provided by the transport 
processor. The destination address is the callsign of the 
requested destination node. The routing processor looks 
up the node in it’s node database (routing table). It will 
find up to three neighbor node callsigns which are in the 
direction of the destination. These neighbor nodes are 
routes to the requested node. If the requested node is un- 
known the message is thrown out. The information sup- 
plied with each route is the callsign of the neighbor node, 
the port number of the route, the quality value associated 
with the path and a flag indicating that a route is already 
in use. If no flag is set then the router selects the highest 
quality route and sets its flag. The port number describes 
whether it’s an over the radio shot or an over the RS-232 
shot. This information is passed to the link manager. 
Slime Trails 

The router knows of up to 100 nodes (adjustable) and 
knows of up to 3 routes per node. If a message, whose ori- 
gin node is not in the routing table, is passed to the router, 
the router notes what neighbor node and port sourced the 
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message and installs the origin node and route into the 
routing table. This way when an answer to that message 
comes back through the node the node will know what to 
do with it. This function is called slime trailing and only 
happens in the event that the origin node is on the net- 
work and knows of destinations within the network, and 
where the network doesn't know of the origin node. Im- 
portant: If the routing table already has 100 nodes in it then 
a slime trail cannot be added. 

The reason that this function is called a slime trail is 
that when a user requests a copy of the routing table (nodes 
list) the slime trail shows up as a node with 
Nodes Broadcasts 

Every 30 minutes (parm adjustable) the node will send 
a nodes broadcast via both it's RS-232 and modem ports. 
This broadcast allows the neighbor nodes to maintain their 
databases of nodes that this node is sourcing. The broad- 
cast consists of all of the nodes whose obsolescence counts 
are equal or greater than parameter 5 "Obsolescence 
counter, minimum for broadcast” and all of the nodes whose 
obsolescence counts are 0 (locked nodes). The format and 
order of the nodes broadcast is basically: 

PQ=256 


nodequal is the highest of the 3 values that the node has 
stored for knownnode. An interesting quirk of TheNET is 
that if the sysop has locked the node itself in that the node 
broadcast will include it as a knownnode. Because TheNET 
nodes believe everything that they hear in the broadcast, in 
the order that they hear it, the node can convince other nodes 
that it is of poorer quality than they have set for the route. 
Circuits 

The process of connecting into a network node, across 
the network, and then out of the network requires three 
operations. The first is called an uplink. The second is 
called a circuit and the third is called a downlink. The up- 
link and downlink stages are AX.25 connections to the link 
processor of each of the two end nodes. The link proces- 
sors pipe directly to the command processors. Circuiting 
means that the command processors pass the traffic to the 
transport processor which then passes the traffic to the 
router etc.. After the router in the origin node gets traffic 
to go to some distant destination node the traffic can hop 
from node to node over more than a dozen TNCs before 
again reaching a transport processor which will be at the 
destination node. The destination transport processor will 
then acknowledge the packet and the process is repeated 
in reverse. At the same time the destination transport 
processor acknowledges the message it sends the message 
to the destination command processor. If the origin trans- 
port processor hasn't gotten an acknowledgment before a 
time-out timer expires (transport time-out) it can resend 
the message. If the origin transport processor gets another 
message from the origin command processor it can send that 
one into the system as well. It can have up to 4 messages 
in transit without having acknowledgments. When the 
command processor attempts to send the 5th message the 
transport processor will respond with a ‘choke’ flag. 
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Preliminaries 
The following steps should be taken in the process of 
getting your new TNPlus node operational: 


TNC Selection 

“Net” type chip nodes work only with TNC2s or clones. 
There may be a problem with noding an AEA PK88. The 
Kantronics series of TNCs will NOT work for this applica- 
tion. Multi-mode type TNCs will not work for this appli- 
cation. Use only a TNC2 or clone (Pac-Comm, MFJ) that 
has the full compliment of 32K memory installed. Using 
the older 16K equipped TNCs will result in failure of your 
node to work. Your TNPlus node chip is a programmed type 
27C256 EPROM and replaces the TNC firmware chip lo- 
cated at U-23 in most TNCs. This TNC chip can be identi- 
fied by the label on top indicating something to the effect 
of “TNC 2 1.2.6” or, “TNC 2 1.2.7”. 

CAUTION! CMOS handling precautions are necessary 
when removing / installing these chips. Never replace com- 
ponents with power applied. The safest procedure is to 
ground yourself, your work area and your TNC during the 
chip replacement process. Keep your TheNET Plus chip in 
it’s protective container until time to insert it into the TNC. 

Current versions of the MFJ 1270B and MFJ 1270BT 
as well as the PacComm Tiny-2 and MicroPower-2 TNCs 
come from the manufacturer TheNET compatible with no 
modifications needed. 


Selecting Mnemonics For Node Ports 


Backbone Ports 

For some time now NEDA has been using the mnemonic 
#NEDA for the name of all its backbone ports. The reason 
for this was twofold: firstly this was an easy way to iden- 
tify a backbone port that was a NEDA participating net- 
work link. Cooperation is rarer in amateur radio than in- 
dividuality and we are proud of the cooperation in the 
NEDA network; and secondly this was an easy way “out” 
of deciding what else to name it! Various network partici- 
pants who wished to show off the name of a node sponsor- 
ing group sometimes would use hidden mnemonics that 
related to their group, i.e.: #CNYPA for Central New York 
Packet Association or some other such “pound” ident like 
#NYEPRA, #NYSPA, #NYS01 or the like. 

The reason it is possible to use the #NEDA mnemonic 
on all of the ports at a site is that the software does its 
routing using callsigns, not node names. The node names 
are around purely for the advantage of the human users 
and are not referred to except during user command pro- 
cessing. When the command ROUTES is given the node 
will respond with the callsigns of the neighbor nodes as well 
as the node names. On a NEDA user port all of the RS- 
232 neighbors (port 1) will have callsign:#NEDA. 


User Ports 

On user ports there is a great propensity toward dis- 
playing the band or frequency of a port in its node name or 
for using airport identifiers. NEDA has since steered away 
from this and is in fact now converting node names over to 
mnemonics or name tags that as accurately as possible de- 
scribe, in a fashion understandable by all hams, the geo- 
graphic location or nearest major city that would be readily 


recognized and later remembered by those finding and us- 
ing the port. Bizarre mnemonics that are a play on words, 
club acronyms or other such labels tend to not only con- 
fuse users but are easily forgotten as to what they mean. 

Another reason why fancy labels are no longer needed 
is that current versions of the software allow rather exten- 
sive INFO texts in which can readily give specialized in- 
formation to stations accessing the port. Typically this 
should always include the frequency of the node, so there 
is little use in naming something like ALB144 or ALB220. 

Preferable to this are names like ALBANY and ALBNY3. 
Make sure to read the information in this literature about 
INFO texts. 

At a recent NEDA board meeting the method by which 
to pick labels that matched a local geographical name was 
discussed at length and W1JFP suggested a presently 
available methodology to consistently convert city names 
longer than 6 characters. For information on this conver- 
sion scheme send a note off to W1JFP @ W1JFP. 


Specialized Ports 

For dedicated links and server ports, it is a good idea to 
pick a label that fits either the application, or to use a ab- 
breviated version of the site’s main user port with a num- 
ber after it. Make sure the info text clearly spells out what 
the port is for. 

Examples of specialized ports in our network are: 
DXCLUS at UTICA node which is the DxCluster uplink, 
and DXKNOX at KNOX which is near Albany NY and 
serves the YCCC/AARA DxCluster run by K2TR. Give 
consideration to where your label will show on the list. This 
was one of the reasons that BBSxxx was chosen for GBBPQ 
and MSYS BBS ops, so that the BBS’s would all be listed 
in the same part of the nodes table! 

If you have any questions on how to set up or name a 
port or node, feel free to contact your nearest NEDA Tech- 
nical Committee member or NRS, or send a note to NEDA 
@ WINY with ATTN: NTECH in the title field. 


TNC Modifications 

Prior to modifying your TNC for TNPlus operation, make 
sure it is functioning normally. Then perform the TNC 
modifications. These consist of: 

Connecting a small wire from RS-232 pin 23 to the 
“common” side of JMP 9, the three pins facing the front 
panel on the board. (not necessary for Tiny 2) 

Perform VHF or HF DCD modifications, as appropriate. 
These modifications were developed and reported on by Eric 
Gustafson, N7CL. They yield improved TNC performance 
and will improve node operation. For the TAPR TNC2 or 
clone, the VHF modification is extremely simple and con- 
sists of adding a capacitor and two resistors to the circuit 
board: Replace R73 with a 180K ohm resistor. Place a 180K 
ohm resistor paral-leled with a .001 Mfd capacitor on the 
underside of U-20, between pins 3 and 6. 

Note: To perform the above modification, it will be nec- 
essary to remove the TNC circuit board. An alternative 
method of doing these mods would be to purchase a TNC 
DCD modification kit from the Tucson Amateur Packet 
Radio group (TAPR), telephone (602) 749-9479. Specify the 
TNC model number when you order. 
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On earlier version TNC-2s it will be necessary to increase 
the CPU clock speed to 4.95 MHz. Check your TNC docu- 
mentation on how to do this. 1990 vintage TNC’s probably 
are already set at this clock speed. Early version TNC-2s 
used at U-3, an LM 324 op amp which is not fast enough 
for 9600 baud RS-232 operation. If your TNC does NOT 
have this chip it probably will operate satisfactorily. If it 
does have the chip. A TL074 or TL084 is a suitable re- 
placement. Modification of the watch dog timer to increase 
it’s time out value does not seem warranted as the 12 sec- 
ond timer value is sufficient. The PacComm Tiny 2 TNC 
comes TheNET ready but it may require a more complex 
DCD modification kit, also available from TAPR. 


Node Radio Considerations 

Radios selected for node use should be capable of heavy 
duty use. The Tx/Rx switch circuitry should be able to 
handle virtually millions of operations without failure. This 
means PIN diode Tx/Rx switching as a first choice followed 
by high quality reed relay switching. Receiver front-end 
filtering should be quite sharp if your node is to coexist with 
other radio services. In that case consider using one or two 
tuned cavities to cut down on front end overload and de- 
sensitization. If your radio is operating on a simplex fre- 
quency, the cavities will also aid in reducing the effects of 
“white noise” being generated by the transmitter. At con- 
gested sites, a circulator may be required. 

Some amateur class VHF radio’s employing PLL fre- 
quency synthesizer technology should be avoided. Two 
reasons: PLL settling time between transmit and receive 
is too slow for optimum packet throughput. Consider the 
following table. 

This is a table of maximum throughput in bytes per sec- 
ond assuming 230 bytes of data per 256 byte transmission 
with a 16 byte acknowledgment, for each popular data rate 
and with different TxDELAY settings which would be the 
same on both ends of a data link: 


baud byte Throughput given TXD of 

rate time Oms 40ms 250ms 350ms 500ms 
1200 6.67ms 127 121 99 91 81 
2400 3.33ms 254 233 163 143 121 
4800 1.67ms 506 431 241 199 158 
9600 .833ms 1015 750 316 248 187 
56K .104ms 8131 2124 435 316 223 


Note that the actual TxDELAY setting in the TNC Parms 
is in tens of milliseconds. Therefore the 500ms values in 
this chart would be achieved by setting the TxDELAY to 
50; 40ms values would be TxDELAY of 4. 

The length of a single byte BYTELENGTH = 8&/baudrate 
The length of one byte of data, including inefficiencies is 
LOADEDBYTE = [(TXD x 2transmissions) + 
(BYTELENGTH x 272bytes)] / 230 

Throughput per second = 1 / LOADEDBYTE 

This means that the speed of the radio's transmit to re- 
ceive and receive to transmit switching is vitally important. 
Also, the transmitter may be keyed before stabilizing on 
frequency. This latter situation could cause interference 
to other receivers on different frequencies. This may be a 
serious concern if you choose a commercial radio environ- 
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ment for your node. If your candidate radio uses PLLs, so- 
licit the manufacturers advice on suitability for packet node 
use. 

In general, retired commercial service FM radios, such 
as the Motorola MICOR and GE MASTR II, or later, make 
excellent node radio choices. The commercial radios are 
designed to operate in moderate to high intensity RF envi- 
ronments, are physically rugged, and fairly reasonably 
priced on the used market. These radios typically come in 
a variety of power levels up to 110 watts (suitable for long 
haul dedicated UHF/6m backbone links; User ports should 
generally run less than 25 watts ERP.) 

If this information is daunting to you then please just 
keep it in the back of your mind. If you are running your 
node out of a non-commercial radio site, like your home, 
then you can worry about this after you have your multi- 
port node up and running. Using ham radio HTs and mo- 
bile rigs you can get things going and then swap out criti- 
cal components later. The most important thing here is 
that you get your multiport node up and running with 
hidden transmitter free backbones. Then you can worry 
about radio and baud rate improvements. 


Node Checkout 

Before placing your node in service, it is a good idea to 
verify modem tone frequency accuracy for each port. This 
can be done by using a frequency counter on the TNC au- 
dio output in conjunction with the KEY MARK and KEY 
SPACE commands. Or by following the modem calibra- 
tion procedure using the firmware chip as described in the 
TNC manual. Carefully save the original TNC firmware 
chips for possible future use. 

NOTE: Sometimes the contents previously stored in 
RAM memory will interfere with node initialization when 
the TNC is first powered ON. This situation has been ob- 
served after replacing the TNC firmware chip with the new 
node chip. The solution is to turn off the TNC and pull the 
battery jumper (JMP 5 on MFu’s) for about one minute. 
This power down process deletes the contents previously 
held in RAM memory. Reinstall the battery jumper and 
the TNC should initialize properly. 

Using a standard RS-232 cable, such as the one between 
your TNC and terminal, connect your terminal to one of 
the TheNET TNCs. Make sure the terminal is set to the 
same as the TNC to terminal data rate on the TNC! (Tiny 
2 data rate is set just inside the front panel. MFJ is set on 
the back panel) Power on the TNC. The STA and CON 
LED’s should go on and then off. A TNPlus sign-on mes- 
sage will appear on your terminal’s screen. Connect to the 
new node by pushing the esc C <enter> keys. The screen 
should now read: 

Connected to <callsign> 

At this time verify the node is working by checking out 
it’s commands. Type: I <retum> H <retum> N <re- 
tum> P <retum> R <retum £S <retum JU 
<retum>, an invalid command such as W <return>, and Z 
<xetum>. You should get an appropriate response back 
from each of these node commands. Operation of the node 
in this manner is called "host interface" and is similar to 
using a regular TNC in the non-monitor mode. You will 
not be able to monitor unconnected packets. 
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A unique password string has been hard burned into your 
“TNPlus” node chip. You will need to remember this pass- 
word string since from time to time you may want to enter 
new material into the INFO section. 

NOTE: From version 2.05, the ESC P command has been 
deleted from the HOST interface. In order to make pro- 
gramming room available for the “KEY” alignment features 
it was necessary to make a trade-off between that and exist- 
ing functions. As a result, it was decided to remove the ESC 
P command from HOST mode. The password string is still 
normally programmed in at time of node chip preparation 
and should be recorded for NodeOp use. 

You may also sysop the node by connecting to radio and 
then connecting to it over the radio. See "Sysop Command 
List" for more details. 

Now that you are in control as the sysop, you can input 
the information into the INFO section. You should insert 
the correct information about your QTH, operating fre- 
quency, contact information and access to servers locally 
in the network. For specific information on how to write 
into the INFO section, review the material presented in the 
"Sysop Command List". 

As sysop, you can also change the parameters. In fact, 
you changed one of them in the example above. The de- 
fault node parameters have been carefully set for your node. 
(It is not recommended they be changed unless you 
have a strong reason for doing so) In general, the node 
parameters modify the nearby node network performance 
in subtle, and sometimes not so subtle, ways. An improp- 
erly set node parameter can harm the overall network 
throughput. Before making any changes, read over this 
manual, your NEDA Annual Membership Package, and 
consult with your regional network sysop. 

Once you have checked out each port individually you 
can prepare to connect them together through the Hexi- 
Pus™ diode matrix. Before you do this you may want to 
lock in the user port node at each of the backbone port nodes 
and all of the backbone port nodes (at the site you are 
building) at the user port node. The reason for this is that 
the automatic nodes broadcasts are the only other way that 
the TNCs will find out about each other and that means 
you will have to wait 30 minutes after hooking the TNCs 
together before finding out if they are working! If you know 
how to lock nodes using the N command then do so. If not, 
hook the TNCs together through the matrix now, with the 
radios off or disconnected, and then continue reading until 
you get to that part of this manual. 


User Command List 
TNPlus v2.08B has the following commands available 
to the user: (Commands may be abbreviated as indicated.) 


BYE 

This command will tell the node to disconnect from the 
user and may be abbreviated to B. This will have a simi- 
lar effect to the user doing a disconnect from his own station. 


CONNECT 

This command instructs the node to connect to another 
station. The command is entered as C STATION where 
station may be a six character or less text string or a valid 
amateur callsign. First the node searches it's own data- 


base for a match between station and a known node name 
or a callsign associated with a known node. If anode name 
match is found then the callsign associated with that node 
is used. If that is the case or if STATION matches a node's 
callsign then a network connect is attempted to the re- 
quested node. 

If no match is found then the node will process STATION 
and determine if it is a valid callsign. If not then the node 
will send an error message to the user. If it was a valid 
callsign then a connect attempt is made via the modem port 
of the node. If successful the user will be sent 
nodecall:nodename} Connected to STATION. If unsuc- 
cessful the user will be sent an error message. 


CQ 

When the node receives a CQ command, it transmits 
once: CQ plus any user text up to a maximum length of 77 
characters, including spaces. The node is also conditioned 
by this action to display the CQing station in it’s USERS 
response for a period of time set by Parameter 15 (usually 
2 hours minutes), unless the CQing station issues some 
other command before the time runs out. Should another 
station perform a USERS command during this time, he 
would be able to see something like this: 
ALBANY :WA2WNI-1> NEDA Node TN208B (695) 
Circuit (MONROE:WB2GNR-1 NM2J) <~~> CQ (NM2J-15) 

Anyone observing the CQ can connect to NM2J-15 to 
initiate a QSO. If you are already on a node port and see 
another station in the USERS list CQing you may also 
connect to the station directly from there. If the CQing 
station doesn’t get a reply after a few minutes, he can re- 
send the CQ command from time to time in hopes of at- 
tracting someone in the local area of the calling node. Re- 
member, each time the CQ command plus text is given it 
will be broadcast in unproto form by the node for just that 
one time. 


HEARD 

The “H” command will display level 2 (normal) users 
heard by the node during the past 15 minute period. Net- 
nodes and level 3 users will not normally be seen once your 
node has “initialized” itself (a 30 minute period after start- 
up). The maximum number of users allocated for the 
HEARD table is 20. Stations listed in the HEARD table 
are not ranked in order of time. I[.e., the first station listed 
may not be either the most recent or the oldest station 
heard. Ifa station has not been heard during the past 15 
minutes, a No One response is given. 

The HEARD function compares the new call with the 
node routing table. If a match is not made, the new call 
will appear on the HEARD list. There will be times when 
either a new node or a propagated node callsign will ap- 
pear on the HEARD list. Following receipt of a node 
broadcast containing the alias for that particular node, the 
node callsign will then be deleted. 

Digipeated and local node downlink callsigns will also 
be listed. If a user notes an SSID of -14 or -15 associated 
with the callsign, the odds are these calls will be uncon- 
nectible since the originating station is separated by one 
or more digi’s or nodes. Stations who are digipeated will 
probably not be connectable and the HEARD list won't 
make this clear. 
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INFO 

Sending this command will make the node respond with 
a block of text that will describe the node's location, fre- 
quency, who to contact, servers accessible etcetera. Ex- 
amples of info messages are: 


WB2Q8Q-1 : KNOX} 
port 144.91 USER 
cnty Albany 


K2TR-10 : DXKNOX} 

Port Dedicated DxCluster Link 

cnty Albany 

QTH Knox, N.Y. 

info WB2Q80 @ WA2PVV 

Enter C K2TR for direct connect to YCCC/AARA 
DoCluster System. 


N2CJ-1: CLV} 

Port 145.09 MHz USER 

cnty Duchess 

QTH Clove Mt. Poughkeepsie, NY 

info N2CJ @ WB2COY 

For automatic routing to WB2COY BBS via dedicated 
link enter C BBSCOY 


NODES 

This command returns a listing of the nodes contained 
in the routing table. It gives a user a listing of possible 
destination nodes for him to connect to. It’s a very good 
practice to use this command at least once every few weeks 
on your local node to learn about network changes. Feel 
free to connect to new nodes on the list and issue the INFO 
command to learn all about the new node. 

Variations on the N command are: N * and N <alias or 
callsign>. The N * command additionally yields a dump 
of the # (hidden) nodes. The hidden nodes are those nor- 
mally associated with backbone trunking. As such it is not 
normally intended for users to connect to them. 

The N command can be used to determine the neighbor 
node and quality for a particular node. The syntax is N 
<alias or callsign>. An example: 

We are at the CANTON node and wish to know the route 
to POTSDM. We issue a N POTSDM command and receive 
back this response: 


CANTON: WA2MZF-5} Routes to: POTSDM:K2Cc-1 
> 186 3 1 #NEDA:WA2MZF-11 
167 3 1 #NEDA:WA2MZF-10 


This tells us there is a route to POTSDM and it is an 
RS-232 path (the 1) via WA2MZF-11 which is a backbone 
node and this route is currently in use. The numbers given 
in the N <alias or call> command will be explained later. 
Here we just want to show how the N <alias or call> com- 
mand is a powerful tool to help one navigate throughout 
the network. 
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PARMS 

(Parameters) Issuing this command will yield a status 
listing of the nodes parameters. There are 33 although only 
16 are answered with by the PARMS command. The other 
17 are only visible during node EPROM setup. 

The node response may look like this: 
POTSDM:K2CC-1} 50 50 230 3 4 1800 618010 35 
201 

Each parameter affects the node operation in one way 
or another. The values chosen for your node will impact 
the operation of the other nodes in the network. The con- 
vention is to number the parameters from left to right in 
the example above, starting 1, 2, 3, etc. See the section 
titled Node Parameters for a complete description of the 
parameters. 


ROUTES 

This command yields a listing of all radio line of sight or 
wire connected nodes known to the node. These nodes are 
called neighbors. The listing will also show nodes and digi 
routes set by the sysop locking commands. Due to the dif- 
ferent protocols involved, TheNET does not recognize KA- 
Nodes, ROSE nodes, or TEXNET nodes in it’s ROUTES list. 
It will recognize G3BPQ, MSYS and compatible TCP/IP 
nodes. A typical ROUTES display may look like this: 
CANTON: WA2MZF'-5} Routes: 

1 #NEDA:WA2MZF-12 230 16 

1 #NEDA:WA2MZF-10 230 3 
> 1 #NEDA:WA2MZF-11 230 12 

0 HULL: VE2RBH 50 1 

In column one we see a 1 for all paths that are through 
the matrix and a 0 indicating a radio path to VE2RBH, 
HULL node. The right arrow indicator tells us one of the 
paths is either in use or has had activity within the past 
15 minutes. All radio paths show a standard path quality 
value of 50 (This is a standard user port). All RS-232 paths 
show a path quality value of 230. The last column indicates 
the number of nodes sourced from this route. 


Sysop Command List 
In addition to the user command listing given above 
there are a special set of commands for System Operator 
use. To be able to use these, you will have to be recognized 
by the node as a sysop. The method for doing this is to 
answer correctly the random set of numbers given in re- 
sponse to a SYSOP command as described previously. 


SYSOP 

After connecting to the node by issuing a “C callsign” 
command, type “S”. S will return you a random series of 5 
numbers. Enter the password string that corresponds to 
these numbers. The node will not tell you that you have 
been successful. To test the success of your SYSOP com- 
mand, type “P <return>”. This will give you a string of 
numbers, representing the default values for the various 
node parameters. Note the value of the first number (typi- 
cally 50). Now type P 51. If successful, the first number 
should come back reading the new value 51. Again type P 
space and insert the original number back in the param- 
eter listing (P 50). 
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Sample password string: 
FRED WAS A BIG AROUND UNTIL TH 

I usually write out my password strings in a matrix so 
they are easy to translate. Thus: 

x0 xl x2 x3 x4 x5 x6 x7 x8 x9 


Ox !! F R E D WaAé=S 
lx A BIG H E R O 
2x A RO UW D H E 
3x R E Ont Rete DG T 
4x H 


Remember that the first valid digit is 01. So, the fallow- 
ing exchange would properly sysop the node: 
cmd: C MITOM 
*** Connected to MITOM 
SYSOP 
K1MEA-1:MITOM} 31 13 40 01 08 
REHE'S 

Note that the node will not return a number that repre- 
sents a space character. To verify that I got in I type: 
P 
KIMEA-1:MITOM} 50 50 230 3 4 1800 618010 35 
201 
P 51 
K1MEA-1:MITOM} 51 50 230 3 4 1800 618010 35 
201 
P 50 
K1MEA-1:MITOM} 50 50 230 3 4 1800 618010 35 
201 

Note that the first parameter changes from 50 to 51 and 
back to 50. It is very important that the parameter is 
changed back! So, if you do this procedure don't change 
the first parameter by too much. If you were to change it 
to 255 and then weren't able to change it back (Your tower 
just blew down) the node would soon become useless. 


INFO 

Allows the sysop to enter text into the soft coded INFO 
section on the node. This new INFO section has available 
a maximum of 160 characters. Up to 80 characters on one 
line is allowed. It is always a good idea to start any info 
string with a blank line feed to allow your info text mes- 
sage to be formatted nicely on the user's screen. This is 
done by entering aI <ctrl A> <returm> for the first line. 
Note that a “I” followed by just a ctr] A will blank the entire 
info message. For text to be entered on the 2nd and subse- 
quent lines, type: I +<text> until the total 160 character 
limit is reached. 

As this technique is different than previously used, a 
little in-house practice is advised until you become famil- 
iar with it. Review the INFO format examples previously 
given for ideas on how you want to set the INFO text for- 
mat. An example for setting INFO: 

Sysop action: I ctrl A <retum> 

Node response: 

ALBANY : WA2WNI-1} : 
Sysop action: I +port 144.93 USER 
Node response: 

ALBANY: WA2WNI-1} 

port 144.93 USER 
Sysop action: I +enty Rensselaer 
Node response: 


ALBANY : WAZWNI-1} 

port 144.93 USER 

cnty Rensselaer 
Sysop action: I +QTH West Grafton, N.Y. 
Node response: 

ALBANY : WA2WNI-1} 

port 144.93 USER 

cnty Rensselaer 

QTH West Grafton, N.Y. 

Sysop action: I +info WA2WNI @ WA2PVV or NEDA @ 
W1NY 

Node response: 

ALBANY : WA2WNI-1 } 

port 144.93 USER 

cnty Rensselaer 

QTH West Grafton, N.Y. 

info WA2WNI @ WA2PVV or NEDA @ WI1NY 

This process can be repeated until the maximum of 160 
characters, including non-typing and punctuation, has been 
reached. 

Note that the key things to tell your connecting stations 
are: What frequency the port is on, What type of port it is, 
Where it is located, and how further information can be 
obtained. 

NEDA Node sponsors who are not readily reachable by 
packet may also put NEDA @ WINY in the info line at the 
bottom if they wish. NEDA promotes live keyboard user 
activity and “hacking” the network to find out what's out 
there and to find new friends and ways of using the net- 
work. Nothing can be more frustrating to a user ham to 
find a nicely implemented reliable network port that has a 
blank info text! Lets prevent this annoyance by carefully 
labeling every port that is put up and what services it is 
intended to perform! 

For further information regarding info texts and setup 
contact your nearest NEDA NRS or send to NEDA @ 
WINY attn: NTECH Committee. 


KEY 

KEY MARK; KEY SPACE or KEY DIDDLE 

Operates the PTT line of the TNC and turns on the Mark 
(high) tone, the Space (low) tone or a diddling between the 
two tones for approximately 22 seconds. 

The purpose of the “KEY” commands are to make the 
NodeOp’s job of setting deviation and RF frequency much 
easier. Previously it was necessary to reinstall the origi- 
nal TNC firmware chip and perform the CALIBRA proce- 
dure in order to set FM deviation. Now if the node-op has 
the appropriate equipment and is within radio range of the 
node, he can routinely check frequency and deviation re- 
motely! At the site, this same procedure can be done via 
the host mode interconnect. Once entered, there is no way 
the KEY command can be terminated until the internal 
timer runs it’s course. If the node watchdog timer is set 
for less than a 22 second duration, the watchdog will un- 
key the PTT. However, the node will continue the KEY 
command until the remaining time has expired. During 
this period, the node will not execute any other commands. 


ON - OFF 
A simplified remote control capability as compared with 
the HIGH LOW commands found in TheNET version 1.0. 
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ON turns on the CON LED and OFF turns the LED off. In 
the MFJ 1270B, the voltage sense from the CON LED ap- 
pears on pin 8 of the DB25 connector. The voltage sense 
also appears on the base of Q16, a 2N3904, the output of 
which goes to pin 2 of the TTL connector. The main cau- 
tion here is that the control switch be capable of passing 
the appropriate amount of current and voltage to the con- 
trolled device. 


PARMS 

Allows the sysop to make changes to parameters. 

To use, type P ***kktkkkkkkee 650 <enter> to change 
parameter 15 from 900 to 650, for instance. The asterisks 
preceding the value to be changed protects the preceding 
parameters from being changed. To change Parameter 4, 
type 

P **% 245. 


NODES 

Occasionally a need may arise to modify node entries in 
the node routing table. The sysop command for this is: 
N NODECALLSIGN + ALIAS QUALITY OBS PORT NEIGHBOR 
(digicalll, digicall2) 

For example: 
N WA2TVE-8 + DXCLUS 58 0 1 WA2WNI-7 

In this example the node DXCLUS:WA2TVE-8 is added 
to the nodes list with the node name of DXCLUS with a 
route quality of 58, and obsolescence of 0 (thus locking in 
the node) via the RS-232 port (the 1) and routed to 
WA2WNI-7 as the neighbor. Setting the obsolescence to a 
non zero value will cause this planted node information to 
be temporary 

To manually unlock DXCLUS, the command is reversed: 
N WA2TVE-8 - DXCLUS 58 O 1 WA2WNI-7 

Note that you can manually remove other nodes even 
non locked ones, at least temporarily, by using this com- 
mand. The values you use for quality, obsolescence, port 
and neighbor must be entered exactly as stored in the nodes 
list. 

Here you will note, we used a minus sign for this pur- 
pose. It is necessary that the unlock command be exactly 
the same as the lock command, with the exception of the 
minus sign. 

Setting the obsolescence to zero permanently locks the 
destination node into your node routing table. Even if the 
locked node fails, it will still be listed in the node routing 
table. A failed node entered as a locked route on the other 
hand, will not be listed in the node routing table if a corre- 
sponding locked nodes command has not been used. 

Note that if 3 neighbors report a higher quality than your 
locked quality in a locked node, that your locked entry will 
be shoved off the nodes list and will not be remembered. 

The locked nodes command to use if a node should NOT 
have an alias is: 

N NODECALL + * QUALITY OBS PORT NEIGHBOR 
(digicall1, digical12) 

Usage example: N AK7Z-1 + * 143 0 O AK7Z-1 
ROUTES 

This command allows routes to specific neighbor nodes 
to be locked in or changed. There may be times a node-op 


will want to modify the path quality value of a route to a 
given node. The locked routes command is: 
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R PORT NODECALL (digicalll, digicall2) + 
PATHQUALITY 

To unlock the routes use: 

R PORT NODECALL (digicalll, digicall2) - 
PATHQUALITY 
An optional use of up to two digi’s can be specified. An 
example: 
R O N2CGY-3 + 143 WA2JWJ-1 WSODA NSAA 
The result of this operation might look like: 
MAL: W2RRY-1 Routes} 
O DKC:W5YI 50 9 
0 CLOUD: W2VXY 192 43 
O WMASS:N2CGY-3 via WA2JWJ-1, WSODA, NSAA 143 1! 

Here we see the exclamation mark which indicates a 
SYSOP locked entry. 

The most common example of locked routes is in a back- 
bone link which is supposed to be protected and dual ended. 
You may lock in the neighbor route and set the radio chan- 
nel 0 path quality (Parm 3) to zero. This protects against 
unauthorized backbone use or misrouting caused by 
propagation or DX. The wanted routes would then be locked 
in at quality 230. This means that all nodes sourced from 
the neighbor will have routing qualities based on the 230. 
See the NEDA Annual Membership Package for more in- 
formation on route quality calculations. 

O DKC:W5YI 50 9 

In the routes list the second value after the neighbor 
callsign (in this case =9) is the number of nodes sourced 
from the listed route. If a route is locked this value may be 
0, indicating that no nodes are sourced from the neighbor. 

Changing the value of an established (but not locked) 
route may also be done with the routes minus command. 
Note that attempts to remove a route which is sourcing 
nodes will not be effective. The best you can achieve is to 
set the route quality to 0. If a node is locked using a route 
you want to remove you must first unlock the node. If a 
node is locked to a neighbor for which there is no route, a 
route will be created automatically at the quality with which 
the locked node is set. 


RESET 

-This command causes the routes table and nodes table 
to be cleared, along with the info message. Any currently 
connected users are lost. 


Host Interface 

When as Node Op, you connect your terminal to the RS- 
232 port of your node, you are accessing the host interface. 
It’s function is to allow you as, node-op to perform house- 
keeping operations. The node is configured to automati- 
cally accept you as the authorized sysop whenever it senses 
your terminal connection. 

In addition to the regular user commands, the host in- 
terface has specific host commands available. These are: 

ESC C - to connect to the node. 

ESC D - to disconnect from the node 

While accessing the host interface, you can (without 
qualification) perform all the other sysop functions that are 
available to you remotely. The host interface is set up as a 
single user application. You, as sysop can access it by giv- 
ing an ESC C command via a terminal connected to the 
RS-232 port. A user can access only if there is no one ac- 
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tively connected to the node via the RS-232 port and if pa- 
rameter 12 is set to(1). Under these circumstances a user 
would connect to the node as normally done. Once the 
Connected to response is received, the user would enter 
another “C” command. The node will then respond again 
with Connected to <nodecall>. At this time communi- 
cations can take place between the user and the host ter- 
minal. 


Node Parameters 


The values given in [brackets] are current default for 
NEDA Network U=USER B=BKBN type ports. 


1. Minimum path quality for automatic updates. 
This parameter sets the minimum value for quality for 
a node to be saved into the routes table. When a node hears 
a nodes broadcast from a neighbor node it processes that 
broadcast in terms of the quality value associated with that 
neighbor node. Any nodes learned about whose resultant 
quality is less than parameter #1 are ignored. If the path 
quality to all backbone nodes is the same, regardless of path 
type or port number the length of the network can be pre- 
dicted based on the path quality and parameter number 1. 
NEDA recommends 50 for this value and 230 for all path 
qualities. This limits the duration in terms of number of 
nodes to 8, multiport, dedicated link supported, nodes. 
(Range: 0 - 255) U - [50] B - [50] 


2. Path quality assigned to radio channel 0 (HDLC 
port). 

‘In a system where time to live (Parameter 18) is used to 
determine the number of backbone hops away from which 
this node will be available this parameter, HDLC default 
quality, should be consistent on all backbone ports. The 
NEDA Network consistently uses 230. For user ports a 
value of 50 is used so that nodes appearing from outside 
the network will show on the local user port. On LAN ports 
this parameter is set to 0 so that miscreant nodes do not 
show up. 

(Range: 0 - 255) U-[50] B - [230] 


3. Path quality assigned to RS-232 channel 1. 

This value is set to 230 on all TNCs so that time to live 
may be used as noted above. Do not set this parameter to 
255 as in a 3 or more port node this can cause feedback 
loops where bad node information may linger for extended 
lengths of time. See NEDA Annual Membership Package 
for more information on path quality and time to live pa- 
rameters. 

(Range: 0 - 255) U -[230] B - [230] 


4, Obsolescence counter initialization value. 

The obsolescence is the number of nodes broadcasts be- 
fore the node information for a particular node is erased 
from the nodes list unless updated by a new nodes broad- 
cast from the appropriate neighbor. 

(Range: 0 - 255) U -[3] B-[3] 


5. Obsolescence counter, minimum for broadcast. 

This sets the limit on the minimum obsolescence value 
associated with each node for it to be included in the nodes 
broadcast. The node doing the broadcasting is always in- 
cluded in the broadcast. 

(Range: 1 - 255) U-[4] B-[1] 

U value only passes itself, B value will allow all currently 
known nodes to be broadcast 


6. Broadcast timer interval in seconds. 

A TheNET node TNC has an internal timer. This value 
sets that timer. When the timer runs out the node decre- 
ments the obsolescence counts for all of the nodes in it’s 
nodes table and does a node broadcast. 

Whatever value is set, it should be the same as that of 
the neighbor nodes. Otherwise it is apt to adversely im- 
pact the operation of some of the previously discussed pa- 
rameters. In other words, indicate poorer paths then what 
really exists if set for a shorter time interval than the 
neighbors. The opposite is true if this timer is set for longer 
periods. It may indicate good paths that in reality have 
gone away. 

(Range: 0 - 65535) U -[1800] B - [1800] 


7. Link time-out (FRACK). 

This sets the time delay after a message is sent to a user 
or neighbor node before the node will attempt a retry. For 
double ended hidden transmitter free backbones this should 
be set to a minimum value, 1. For user ports, setting this 
value higher gives priority to those users that are most 
consistent into the node. 

(Range: 1- 15) U-[3 to 6] B -[1] 

User port value depends on channel loading / sharing re- 
quired 


8. Link layer MAXframe. 

This sets the number of packets that are available in 
memory to send to a user or adjacent node that will be sent 
in one transmission. See NEDA Membership Package for 
further information regarding this parm. 

(Range: 1-7) U-[1] B-[1] 

This value insures equal network wide loading charac- 
teristics regardless of the type of application requesting a 
circuit. This insures that All applications get uniform 
network response . 


9. Link Layer Maximum retries. 
(Range: 0-127) U-[6to10] B -[8 to 14] 
Depends on channel loading / sharing characteristics 


10. Digipeating. 

If this function is enabled(1), it allows users to subvert 
the normal network flow by assigning priority to the digi- 
peating station. The default of disabled(0) is recommended. 

(Range: 0-1) U-[0] B-[0] 

See the NEDA Membership package for info on why it is 
important to have this value OFF. 
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11. Validate callsigns. 

A user, upon misstyping a C ALIAS command, will have 
to wait for a period of time dictated by link layer FRACK 
and retries before being informed of a failure. If enabled, he 
would only have to wait for the period of network propaga- 
tion delay before getting an Invalid callsign response. In 
some cases, this could save the distant user 10 to 15 min- 
utes. If the NodeOp is desiring to allow users to downlink 
to KA-node aliases, possibly these aliases could be named 
so they will satisfy the callsign verification criteria. Le., 
no more than 6 characters with one number included. For 
example: CDXBOX (note the zero in “BOX"). Callsign vali- 
dation enabled also prevents those who forget to install their 
callsign into the TNC from uplinking to the node. The node 
response to a NOCALL is Nede busy. Default is “1”. 

(Range:0-1) U-[1] B-[1] 


12. Host Mode connects. 

ON (1), OFF (0). 

When a NodeOp has a terminal connected via the RS- 
232 Host Interface, ON (1) will allow users to connect to 
him IF he is not actively connected to the node at the time. 
Off (0) prevents users from connecting. 

(Range: 0-1) U-[0] B-[0] 


13. Node radio TXD. 

TxDELAY in a TheNET node is the same as TxDELAY 
ina TNC2. This adjusts the period of time between keying 
thre transmitter and when it actually starts sending data. 
If this value is too short the receiving station will not hear 
the start of the packet and a failure will result. If this value 
is too long then data throughput will be less than optimal. 
TxDELAY is adjustable in 10 MS increments. 

(Range: 0 - 255) U - [35] B - [5 to 35] 

User ports should not be shorter than 35 or you will ex- 
clude stations with slower switching radios from using your 
user port. Backbone ports should be optimized to find the 
absolute lowest value that will work reliably with all other 
radios on its backbone link, then bump the number up a 
few notches so switching delay drift doesn't interfere with 
reliable Tx/Rx switching. 


14. Broadcast via port. 

Nodes broadcasts occur once each half hour (depending 
on nodes broadcast interval parameter). This parameter 
allows the sysop to disable nodes broadcasting on one or 
both ports. The reasons that this might be done is to ° 
discourage node operation on the modem port and reduce 
clutter on the frequency or ® hide the node or ® in concert 
with locking the node in at another location this can be used 
to create a gateway or dedicated use link. 

0 = Broadcasts disabled on all ports. 

1 = Broadcasts enabled on port 0 (radio) only. 

2 = Broadcasts enabled on port 1 (RS-232) only. 

3 = Broadcasts enabled on both ports 0 and 1 

(Range: 0-3) U -[2,3] B -[3] 


15. Hidden Node Propagation. 

This causes # nodes to either be propagated or not. # 
nodes are usually used for backbone links. In the NEDA 
network there are about 60 user ports and about 100 back- 
bone ports. As the TheNET node can only afford to have 
about 90 nodes in it's node routing table it would be impos- 
sible for a single TheNET node to have the entire network 
in its table at the same time if # nodes were to be listed. 
This command is normally left off in the NEDA network. 
Also keeping this parameter turned off reduces the length 
of a nodes broadcast if there are any # nodes in the local 
system. 

(Range 0or1) U-[0] B -[0] 


16. Connect Command Enable. 

If set to 0 connect commands typed after connecting to a 
node are quietly ignored. This prevents stations from do- 
ing manual L2 connects from a backbone node. 

(Range Oor1) U-[1] B-[0] 


17. Maximum number of nodes in NODES list. 

Both hidden and non-hidden, in the node routing table. 
If this number is set too low, say to 1, you will limit the 
number of neighbor routes that show up in your ROUTES 
table. In other words, your node will not recognize more 
than one network node. 

(Range: 1 - 400) U-[100] B - [100] 


18. Time to live. 

This is the number of node hops that a message from 
this node can go before it is killed. Each message trans- 
mitted through the network by a node has an associated 
time to live. Each time the message is received and re- 
transmitted by any TheNET node the time to live for that 
packet is message is decremented. If the time to live 
reaches 0 the message is thrown out. This parm sets the 
time to live start value for each message originated by this 
node. 

(Range: 0 - 255) U -[18] B - [18] 


19. Transport layer time-out. 

Sets the number of seconds that your local user port will 
wait before retrying a packet across the network. In this 
time the destination user port must acknowledge the packet 
and that acknowledgment must make it back to the origin 
user port. If the packet is retried there will be a second 
redundant copy of the message heading across the network 
even if the first copy successfully arrived. This value must 
be set to the maximum amount of time that it will take for 
a packet to travel the number of hops as set by parm 18 
and parms 1, 2 and 3 and for the acknowledgment to re- 
turn to the node of origin. 

(Range: 5 - 600) U - [300] B - [300] 


This gives a 6 minute time-out 


20. Maximum transport layer tries. 

Sets the number of copies of a given packet that the ori- 
gin user port will send into the network to the destination 
user port, timed by parm 19, before declaring the path dis- 
connected. Hopefully the TheNET software in conjunction 
with nodes routing information will be able to try alternate 
paths to achieve a response from the destination node. 

(Range: 2 - 127) U - [2] B - [2] 
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21. Transport layer acknowledge time. 

This is the amount of time a port waits before acknowl- 
edging a transport layer packet that was received. Faster 
is better here unless the port will be under continuous heavy 
loading from the same destination node. 

(Range: 1-60) U-([1) B-[1] 

Faster is better here unless the port will be under con- 
tinuous heavy loading, then a value of 2 or 3 is appropriate 
to allow the link to “piggyback” thru data with the acks. 


22. Transport layer busy delay. 

In the event that a transport layer circuit cannot handle 
more data (parm 24) a busy flag is generated. This param- 
eter is the number of seconds that the origin node waits 
before retrying a message that was lost due to the busy 
condition. When the busy node clears it also generates a 
packet back to the origin node announcing that it is clear. 

(Range: 1- 1000) U-[180] B -[180] 


This equals 3 minutes 


23. Transport layer window size. 
This is the number of unacknowledged packets that can 
be outstanding for a given circuit (each user connect). 
(Range: 1-127) U-[4] B -[4] 


24. Congestion control threshold. 

This is the number of packets that can be buffered in a 
user port for a given circuit. 

(Range: 1-127) U-[4] B-[4] 


25. No-activity timer. 

This is how long a user may stay connected with no traffic 
flowing between the node and his station. On version 2.05 
and later also sets the life of the node STA light following 
the last user disconnect. 

(Range: 0 - 65535) U -[7200] B - [900] 

The higher value on a user port here allows users to hang 
out on CROWD ports and special servers i.e.: DxClusters 
for extended periods without being tossed off for lack of ac- 
tivity. 


26. P-persistence. 

This figure determines the aggressiveness of the TNC's 
transmit function. A high value of P-persistence will cause 
the TNC to be very aggressive. If there are more than 2 
TNCs waiting to transmit on a single channel and their P- 
persistence is set incorrectly the data throughput will suf- 
fer. A formula used to calculate ideal P-persistence is Pp = 
(256/N-1)-1 where N is the number of TNCs on the chan- 
nel that could have data to go out at the same time. So, if 
the channel only has two TNCs the P-persist could be set 
to 255. If the number of TNCs is 3 then P-persist could be 
set to 127. 

(Range: 0 - 255) U -[32 to 255] B - [255] 

_User ports depend on type of port and if it is shared by 
other nodes within direct RF connect range. Backbone port 
value assumes dedicated end to end HTS free link. 


27. Slot time. 

This value should equal the TxDELAY for the node plus 
the worst response delay for other stations on the frequency. 
For dedicated point to point links (2 radios on a frequency) 
this value is unimportant as P-persistence when set to 255 
overrides the value of slot time. As with parm 26 this value 
depends on the type of application. Parameters 26 and 27 
work together to set up a random delay determining when 
the node will key up following a DCD decision that the 
channel is clear. This is an anti-collision technique. When 
the node is ready to transmit, a number between 0 and 255 
is internally generated. If the random number is equal or 
less than the value set by Parameter 26, the node keys im- 
mediately upon sensing a clear channel. If the internally 
generated number is greater than the value of Parameter 
26, the node waits for a period of time equal to the slot time 
and then internally generates a new number, etc. A value 
of 63(+1) is 25% of 255(+1) and thus sets the percentage of 
time the node will immediately keyup. Protected trunking 
nodes (those with only one transmitter on their receive fre- 
quency) would have faster throughput if there were no node 
keyup delay. Setting parameter 26 to a value of 255 will 
accomplish this. 

(Range 0-127) UorB -[TxDELAY of radio] 


28. Link Layer time-out (Resp Time). 

10s of miliseconds between receiving a packet from a 
neighbor node or user before the node will acknowledge a 
packet. This is actually the response time in Ms. Setting 
this value too low on a user port will prevent some users 
from being able to access the port as older radios and some 
newer rigs with very slow locking synthesizers will not re- 
cover from transmit fast enough. 

(Range: 0 - 6000) U -[75 to 100] B - [15 to 35] 


29. Link time-out timer (CHECK). 

This parameter sets an idle link timer. Ifa link is inac- 
tive for this amount of time a check packet is sent to make 
sure the other end is still there. 

(Range: 0 - 65535) U -[65000] B - [65000] 


30. Station ID beacons. 

Kither ENABLED (2), CONDITIONAL (1), or DIS- 
ABLED (0). This directs the node to ID either every 10 
minutes, only after activity, or only imbedded in AX.25 
packets. If the node is addressed using the mnemonic by 
users it will not be properly identified with the AX.25 
packets and must be set in either the ENABLED or CON- 
DITIONAL for user ports. For backbones each node is only 
addressed by callsign so ID beacons may be disabled. 

(Range: 0-2) U-[1] B-[0] 


31. CQ broadcasts. 

ENABLED (1), DISABLED (0). Disabling this feature 
means the unproto CQ user text will not be broadcast by 
the node. The CQing user will still be able to be seen by 
someone doing a USERS command during the time the CQ 
is active. 

(Range: 0-1) U-[1] B-[0] 


32. Heard list length. 

Sets the maximum limit on the number of stations that 
can be listed in the Heard table. 

(Range: 1-20) U -[20] B -[4] 
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ON (1) or OFF (0) 

This option is only turned on if a full duplex radio set is 
employed for a backbone. 

(Range:0-1) U-[0]B-[0] 


Hardware For Node Construction 

Dual Port Operation 

See the NEDA Annual Membership package for more 
information on node construction. Briefly, to make a dual 
port node operate using MFJ-1270B TNC’s you will need 
to make a cable using a pair of DB25 connectors. To doa 
dual port using Tiny-2s you'll need to make a cable using 
a pair of DB9 connectors. Here are the schematics: 
Multiport Operation 

Multiple TNCs and radios can be interconnected to form 
a “node stack”. A diode matrix is used to route the signals 
in proper sequence between the TNCs. The NEDA Hexi- 
Pus™ is a 6 port commercial grade kit containing diodes 
PC board and DB9 connectors that attach directly to the 
PC board. This product greatly simplifies assembly of a 
multi port network node. To get a HexiPus™ send a check 
or money order for $33.93 (for U.S. delivery only) to NEDA 
PO BOX 563 Manchester, NH. 03105-0563. 


Common Problems 

Read this before you launch the missiles. 

ee elf the node is doing funny things like: 
¢ only working over the radio or only working over RS- 
232 
not responding at all 
using the wrong callsign or node name 
transmitting all the time 
not handling the LEDs right 
disconnecting everybody once in a while 
never nodes broadcasting or ignoring incoming broad- 
casts entirely 
Try sysopping the node and using RESET or if you have 
local access you can turn off the TNC, remove the battery 
jumper for more than 30 seconds, replace the jumper and 
then turn the TNC back on. 

¢¢ elf your new node stack doesn't allow you to connect 
across the matrix, make sure that you have waited long 
enough for nodes broadcasts to work. The nodes broadcasts 
over the matrix happen at the same time they do over the 
radio. Just because the TNCs are stacked they don't nec- 
essarily know about each other. It is possible using the 
Sysop:Node command to lock in each port in your node stack 
to each other port so they begin communications immedi- 
ately. This is a good way to get used to doing sysop com- 
mands. 

°° elf you have any other problems or figure out a prob- 
lem for yourselves make sure you send a message about 
this to NEDA@WINY attn.: tech documentation. 


In keeping with the high standards set by the 
NORD><LINK people, the production of TheNET Plus is 
placed in the public domain with the understanding it is 
NOT to be used commercially. We only ask that you share 
this material with like minded individuals. 

73 and enjoy! 

Bill Beech, NJ7P - 12/30/90 
sss subsume i eee nn EY 
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NPUB messages. Jim says that NQ1C 
will talk about that later. Jim says 
that WA1TPP’s MSYS board has a 
phone line that will allow access to the 
network at BERK node to anyone that 
has a password. See the last 
Quarterly’s server section for that 
number and other info. 

N1IFCC BELCH 
Dave, N1FCC says that the BELC 
node is not stable right now but that 
he will report back. He’s currently 
working on trying to get a TCP link 
from KA1JY in Connecticut into the 
BERK repeater via his node. He 
mentions that he is looking into NOS 
as an alternate to the MSYS code that 

he is currently using. 
BERK 440 repeater 

A discussion about the BERK 440 
packet repeater was held with 
WA2VAM, K1MEA and NIFCC. 
Dave, N1FCC, mentions that his node 
shows at the BERK repeater but does 
not propagate from there into the net- 
work as his system is transient right 
now and his node’s NEDAness is in 
question as well as it is MSYS based. 
WA2VAM asks “How many nodes are 
currently being linked to via the 440 
repeater”. Jim lists off NQ1C-8 
(SPRFLD), KIMEA-6 (BBSMTM), 
N1FCC (BELCH), K1IMEA-4 (MTM), 
WAI1TPP (BERK). Jim thinks that the 
repeater solution is excellent for a user 
port operation. Jim thinks also that 
the work that he and WAITPP are 
doing with trying to make the servers 
that are accessing BERK share the 
channel better is proving to have good 
results. Jim thinks that it is good that 
we are learning how to use the re- 
peater as a packet LAN. 
Repeater negatives 

Kevin, WA2VAM, mentions that he 
is a little scared that we are using the 
repeater as a 5 way backbone link 
where he had enough trouble trying to 
get a 3 way to carry traffic. Perhaps 
it is cheep to do the repeater as a 
backbone but does it give us propor- 
tionally cheep or worse results? Kevin 
is worried that we will depend on the 
repeater and get in a jam later as more 
links rely on the repeater. He says 
that even though it is more expensive 
to run dedicated point links that per- 
haps doing so would enhance develop- 
ment and would be worth it in the long 
run if not in the short run. 


Losing 221 band 

Jim brings up that the servers are 
very dependent on the low end of 220, 
specifically the mess on 221.11. There 
is some Connecticut on 221.05 as well. 
Jim is worried that the link that MTM- 
NCMA-CENTMA has on 223.56 might 
get crowded out in the near future. 
SWNH now 4 ports 

Arny, N1BAC, mentions that 
SWNH is now a 4 port node with a 
dedicated link to W1FYR BBS called 
SWNHU and a 440 link down to 
NCMA node. He says that they are 
trying to get WA1FHB to move over to 
SWNHU as well. 
N2GTE BBS software 

Bob, NQ1C, mentions that N2GTE 
has a BBS software package that per- 
forms remote service requests to other 
N2GTE PBBSs to try to resolve user 
forwarding questions, i.e. where is this 
user?. 
BBS “open channel” concept 

Dana mentions that Tadd, 
KA2DEW, has an idea a while back 
that the PBBSs code authors might 
want to allow the PBBSs to create 
“open channels” to neighboring PBBSs 
so that forwarding could take place 
immediately instead of once or twice 
per hour. This might make it unnec- 
essary for PBBSs to do long haul for- 
warding in the hopes of having the 
message get there faster than by for- 
warding it to a neighbor. Participat- 
ing PBBSs would have guarantees 
that messages passed by the “open 
channel” would be delivered as fast as 
the network could. NQ1C mentions 
that the N2GTE solution is to resolve 
“where to forward a user message”, not 
the same as what Dana was talking 
about. 
ALBANY-> SRTOGA gateway 

Dana reports that the gateway @ 
Albany to SRTOGA is on the air so 
BBS forwarding can now go across that 
link instead of via WMA220 which is 
a HTS channel. He mentions that the 
radio that was supplied by Saratoga 
RACES for the ALBANY site has a 
VCO lock problem and although it 
currently works Dana is in doubt of it’s 
future. He says that to get to the 
SRTOGA system or points north 
should connect to ALBNY3 and then 
SRTOGA. Then connects to BBSUMX 
may be done. This is the sequence 
recommended by the Saratoga RACES 
group. Forwarding north through that 
system is not being encouraged. What 
they have working now up to GFL 


node is doing extremely well and is all 
high speed stuff. Dana reports that 
they have learned that the 3 way HTS 
free link that they have has not ad- 
equate and that they will be breaking 
it up and turning it into point to point 
double ended link. Dana reports that 
the SCR system of SRTOGA, GFL and 
SCR/BBSUM<X is doing very well and 
that as that group is learning and 
spreading it’s technology that they 
may be adding some nodes. The only 
thing that they don’t have in the sys- 
tem right now is a dedicated user only 
LAN channel. All of the user ports in 
their 3 node system are on crowded 
2meter channels that have BBS for- 
warding and other nodes. Anybody 
experiencing problems with the gate- 
way should send a message to 
WA2WNI @ WA2PVV as Dana is try- 
ing to keep it running at tip top shape. 
In 6 weeks the gateway hardware is 
supposed to be upgraded to better 
stuff. 


NESAC committee report: 

Dana reports that the committee 
has be quiet due to their own emer- 
gency departments high activity due to 
repercussions from Desert Shield and 
Desert Storm. 
xxRACE & xxARES 

The only thing that NESAC has 
done this quarter is to put out an ad- 
visory about how to connect to the 
state EOC PBBSs and to send to 
xxRACE for races messages to xx-state 
and xxARES for ARES traffic to XX- 
state. NESAC is encouraging local 
emergency services bodies to take ad- 
vantage of packet emergency services. 
New redundancy achieved 

Jim reports that now that NCMA 
talks to SWNH on UHF that there 
exists redundancy between CANDGA 
and SNH. This assumes the 145.05 
hop between WMA and MTM (very 
crowded) and the 223.56 hop between 
MTM and NCMA (not too crowded). 
What we need is another path across 
southern Vermont to give redundancy 
that does not depend on the 145.05 
hop. 
Site Hardening 

Dana reports that NESAC is pro- 
moting ‘site hardening’ so that nodes 
will have battery backup and won’t go 
off the air at the drop of a hat. Cal is 
providing advice on this subject. Site 
operators should pay attention to good 
operating practices and do whatever is 


Continued on page 28 


N.E.D.A. Quarterly v2.2 page 27 


Minutes from page 27 


possible to provide site reliability un- 
der emergency conditions. 
Lead acid batteries available 

Dana announces that he has a 
source of a trickle supply of nearly new 
batteries to run sites on backup. Bob, 
WB2QBQ, has a couple with him that 
he'll discuss delivery of during one of 
the breaks. Bob says that he has about 
$12.50 into each battery and they look 
to be about 60 amp hour. 

The batteries are mostly Panasonic 
and look to be worth about $200 a 
piece. These will be made available 
through WB2QBQ or WA2WNI. A 
show of hands was looked for to see 
how many of the batteries would be 
used by those present. Twenty three 
batteries were determined to be 
needed by those present. No action 
was taken on this. 

Voltage drop problem 

Jim mentions that when he power 
failed CHSTR to test the voltages that 
the TNCs failed he found that the 
TNCs failed at odd voltages between 
11 and 12 volts but that the radios still 
worked at 10.5 volts. He was thinking 
about using NICAD cells for backup 
because NICADs stay at rated voltage 
until just before failure. Memory 
problems with NICADs would kill 
them unless they were deep cycled. Of 
course murphy would cause the power 
to die during the deep cycle process. 
Jim did recommend that the TNCs 
should be run on a separate battery 
than the radios because the TNCs fail 
at the higher voltage. 

Someone in the audience suggests 
that the current conversation has 
taken a little too long. The chairman 
closed the emergency services report. 


Technical Committee Report 
TheNET 2.08 available 

Dana and Tadd prepared manuals 
on the 2.08 product that is based on the 
work of N700. 
GE radios 

Dana sold 30 or 40 of the GE radios 
that are helping to get some nodes on 
the air and upgrade others. See Dana 
for info. They were GE Master Exec 
IIs and were sold for between $30 and 
$50 for VHF HI and LO band. 
Hexipus boards 

A few of the Hexipus boards have 
been sold but there was some delay 
due to slow ups in delivery of the 
documentation. 
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Node naming 

One of the things that was supposed 
to happen between last meeting and 
now was that Tadd was going to pre- 
pare a write up on naming nodes and 
that nodes in our network were going 
to be named such that the name was 
as meaningful in the description of it’s 
location as possible. Tadd is not at the 
meeting and no document has been 
presented. Some nodes in the mean- 
time have been renamed. ALBANY, 
KNOX, AUBRN1, and SYRCUS are 
good examples. 

New nodes on the air 

NEWARK node is on the air linked 
to AUBURN 

BRKPRT node is west of Rochester 
and is on a 3 way with WXFLD and 
MONROE. 

BELNAP is on the air 

BUFFLO node is back on the air as 
a NEDA node. 

KNOX now has a 10m port called 
NYDX10. 

Potential nodes and meetings 

POTSDM and CANTON nodes are 
on but are not tied into the rest of the 
system. 

A regional development meeting 
was held in Scranton Pa [see article in 
this issue titled “Regional Technical 
Development Meeting: Scranton Pa] 
Nodes, Western NY 

A couple of other nodes that are 
about to come on (some of these have 
been about to come on for about a year 
now) ROCH [now on line :ed], 
ALFRED [now on line] and WARREN, 
SHERMN, FRKVIL [which are now 
linked in :ed] 

Nodes, Ontario 

Eric, VES3NUU, whois from Toronto 
Canada has been working with many 
hams in Southern Ontario to create a 
bunch of NEDA nodes to tie Western 
NY to Ottawa and Montreal via a path 
north of Lake Ontario. These would 
be KINGTN, BELVL, COBURG, 
PICRNG, TOR???, and Wellum (Font 
Hill) and that would completely sur- 
round the north end of the lake. Part 
of this would be funded by DxCluster 
enthusiasts in Toronto. The plan is to 
link Font Hill to SHERMN via a 4800 
baud backbone. 

Node, ULSTER + link to ROSE 

Dana announces that there may be 
a new node in Kingston NY called 
ULSTER that is important to us for 
two things: First of all it will be an- 
other ‘home node’ and we might get 
into a discussion on that later and 


secondly it will provide us with a break 
out south bound in the vicinity of CLV 
which was previously unavailable in 
that region. This site might also be 
used as a gateway into the ROSE net- 
work that is spreading out in New 
Jersey. Dana says that NX2P wants 
to set up a ROSE network based on 
NEDA technical guidelines to demon- 
strate that ROSE will perform as well 
as TheNET (if not better) under the 
same radio - link conditions that 
NEDA uses for it’s backbones. 
ALBANY to SRTOGA gateway 

Rich says that the ALBANY to 
SRTOGA is on line now. He brings up 
the point that there was some misun- 
derstanding between the parties in 
regards to how the gateway works 
compared to how the SRTOGA group 
thought that it would work. 

G.A.N.I. Document 

WB2JLR thinks the GANI isn’t 
clear enough and might be expanded 

NRIN proposed that the GANI 
should be a source of all of the info that 
a node op would need to decide about 
getting involved with NEDA. He said 
that currently he understood that the 
GANI was not to be given out blind. 

WA2VAM wanted to know why we 
can’t give it blind. 

WB2JLR said that it wasn’t given 
blind because it was a short and to the 
point list of definitions and conditions 
for a node to be part of the NEDA 
network. K1MEA agreed and said 
that it could be given to a non-member 
if the giver filled in the missing details 
and was around to answer questions. 
Dana brings up that it was he that 
made the motion about how the GANI 
was to be given out at a previous board 
meeting. The purpose was that, as 
Kevin had just said, that it was easy 
to misconstrue if you were not familiar 
with the our network how NRS activi- 
ties should take place and how to 
gateway The purpose was to have 
personal contact with someone to ex- 
plain it so that it would not be mis- 
construed. There was never any indi- 
cation that it could not be shared with 
a non member or with a non-node op- 
erator but merely that it shouldn’t be 
given in the blind or just mailed to 
people so that maybe it could be viewed 
in the wrong light of perhaps an envi- 
ronment where people do not have the 
operating methods that we have. Rich 
read the relevant sections of minutes 
from various Quarterlies. Rich stated 
that if anybody wants to promote 


NEDA or convince someone to get in- 
volved they can photocopy sections of 
NEDA literature. The GANI doesn’t 
explain many particulars of how the 
existing methodology is supposed to 
work. Dana says that he is open to 
somebody else tackling some of the 
documentation gap. Rich suggests that 
since Tadd is the editor that perhaps 
he would be the person that should 
receive any improved write ups. 
G8BPQ nodes 

Rich brings up the question of how 
G8 nodes should be handled and says 
that that kind of things should be 
documented as well. Perhaps the 
GANI should include information 
about server ports and connections. 
Lindsay and Rich talk about propos- 
ing a change to the GANI. Jim sug- 
gests that interested parties should 
rewrite the GANI and that throwing 
things back at Tadd who is currently 
a student might not be bright or suc- 
cessful. A consensus is arrived at by 
all of the board members that some- 
thing needs to be done about it but 
nobody volunteers. Dana suggests 
that the next membership package 
could contain a more severe break- 
down of what it is to be part of the 
NEDA network, to have a gateway etc.. 
Elmira educational tool 

Rich shows the document that was 
created in the Elmira area as an edu- 
cational tool. 
Questions to go to Dayton 

Rich asks if there are any questions 
to be passed to certain software writers 
that might show up at Dayton that 
Rich would corner those people with 
such questions. If anybody wants Rich 
to do this they should mail Rich a 
packet message with those questions 
before the Dayton hamfest. 
WZ2B’s Collision Detector 

Rich talks about a device that WZ2B 
invented that counts collisions on a 
Hexipus. 
Taddad’s Packet Glossary 

Dana shows off the packet glossary 
that Tadd produced. 
KC3BQ technical document 

Kevin talks about the technical in- 
formation that KC3BQ produced for us 
back in December 89. (KC3BQ is re- 
covering from a major cancer opera- 
tion). 
10 meter gateway and nodename 
bug 

Dana announced that EASTNY 
10m gateway at KNDRHK was re- 


moved and replaced by NYDX10 at the 
KNOX site. The new gateway is a 
Kenwood 440 with a TH6DX beam at 
50’. This is far better than the 
KNDRHK version that was 10 watts 
into an omni on the ground. Dana says 
that there is a bug in TN2.08 that 
wouldn’t accept NY10DX as a node 
name. Dana says that he sent a note 
about this to Bill, NJ7P asking if this 
were a feature or bug. Linds thinks 
that the software may have a check so 
that it doesn’t think that a callsign is 
a nodename and thus it won’t take the 
number in the middle of the node- 
name. 

KNOX node enhancemenis 

Dana announces that the KNOX 
matrix was made to be 8 ports with the 
addition of the NYDX10 node. Appar- 
ently a hardware failure coincidentally 
developed at that time which caused 
a TNC’s RS-232 driver to die. Tadd 
happened to be there at the time and 
pulled his mobile TNC and used it to 
build a matrix coupler wireline so 
KNOX is now two 5 port nodes. 

Dana announces that ALBANY and 
KNDRHK as well as KNOX are all 
TN2.08B now. WMA user port is back 
on the air after a month of downtime. 


Hexipus Project Committee 
report 

4 Hexipus boards have been sold. 
Copies of the WB2JLR HexiPus docu- 
ment were sent out as promotional 
items. Rich passed around copies. 
Rich mentions that Tadd’s Hexipus 
document hasn’t materialized due to 
Tadd’s school commitments and house 
fire related problems. Rich relates the 
information printed in the previous 
Quarterly’s front page article. 


Editor’s report 
Tadd isn’t here but Rich comments 
that he thinks the Winter Quarterly 
was spectacular (general agreement) 
Cal comments on how nice the 
documents that Dana passed out are. 


Maps 

W1JFP, Cal, handed out his latest 
version of maps and asked for correc- 
tions after lunch. He also asked for 
updates from everybody out in the 
network to send factual and current 
information whenever anything 
changes that should be reflected on the 
maps or whenever any details that are 
found on the maps that are wrong. 
Also whenever any nodes are put on 


the air that are to be temporary or if 
any nodes that are local slip through 
the cracks (like BOB DANA etc.) 
please send Cal an OOPS message so 
he doesn’t go and try to put it on the 
map and rip out what’s left of his hair. 
This way the maps can be done and 
done right. He says that when he 
makes his maps he goes around and 
asks all of the nodes for an info text 
and routes and sometimes nodes. 


OLD BUSINESS 
TCP/IP experimentation 

Bob NQIC relates that testing has 
not taken place but will any day now 
as he is working on acquiring the nec- 
essary PC for his end. Rich mentioned 
that Chris, WZ2B (the other end of the 
TCP test) was off the air due to dam- 
age caused by the ice storm and that 
Chris is looking forward to working 
with Bob on it. 

Dana reported that KB3YV at the 
Scranton meeting was down on 
TheNET networking for IP. 

Info text 

Cal remarks that the info texts are 
still not even close to being standard. 
The frequency of a user port should 
definitely be added to the info texts of 
all nodes or information as to what 
dedicated link it is. 

Rich mentions that the info text on 
the Maine .03 nodes is very nice and 
maybe we should copy from them. 
Especially considering how easy it is 
to change info texts with TN2.08B. 
Documentation of NEDA 
administrator’s functions 

Rich thinks that we need to have a 
clearer picture of what the rules are for 
new nodes and servers etc.. This must 
include who deals with new parties, 
how the information about the intent 
of a new node or server is. 

Dana brings up that he requested 
that documents be created, way back 
at the spring ’90 meeting, that describe 
what each and every appointed and 
voted position is, does and means. We 
are a big enough club now that we are 
going to need this in order to have the 
club function in a way that is socially 
acceptable. Dana tosses up a proposal 
that somebody who is currently not 
active in club administration should 
come forward and work on this kind 
of documentation. This would help in 
the inconsistent responses that the 
current administration staff tend to 
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see and to make. This is a real prob- 
lem. Dana mentions two symptoms of 
this problem. Dana makes allusions 
to a recent encounter between Linds, 
NRI1N, as NRS, and Tadd, KA2DEW 
as node op of SNH. Dana thinks that 
we should leave this meeting with 
some kind of solution to these kinds of 
problems. 

Tadd and Linds 

K1MEA reviewed the problem: 
Linds was working with KB4N to 
compromise with KB4N. KB4N 
wanted to carry the NEDA nodes list. 
The NEDA policy, which is poorly 
documented, states that this is bad. 
Linds was working with KB4N to 
make his station more like a NEDA 
node so that the questionable ‘bad’ was 
fixed. Jim, K1MEA noted errors oc- 
curring in the NBOD/NTECH distri- 
bution lists where he knew that mes- 
sages were getting sent that weren’t 
getting received. Linds must have 
missed a message that WB2JLR sent 
via NTECH stating the Technical 
Committee Chairman’s position. Jim 
also believes that neither he, nor any- 
body else, in our organization under- 
stands the G8BPQ code’s emulation of 
TheNET. Jim thinks that Tadd acted 
wrongly in taking action and that a 
phone call to Linds would have been 
in order. 

Linds spoke up and said that the 
problem was that the situation kept 
changing. 1> He [KB4N] was not a 
NEDA node 2> He is capable of doing 
level 3 across the network. 3> The 
solution that NR1N was working to- 
wards was based on a technical fix to 
the problem. The problem seems to be 
that many NEDA officers and appoin- 
tees are against the concept of using 
G8BPQ in the network. 

Further discussion occurred which 
included a request for somebody to 
create a statement of what the NRS, 
node owner, tech committee chairman 
and board member should have as 
roles and responsibilities. 

Rich restates the issues: There is a 
technical issue about whether outside 
nodes should be allowed to lock in 
nodes outside our system. Enforce- 
ment, implementation and documen- 
tation of that needs work. The other 
issue is whether an NRS or tech com- 
mittee chairman may reconfigure a 
node in someone else’s territory. 

Jim restates that he wishes for 
documentation describing what each 
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person is responsible for. NRS cover- 
age area must be defined, Jim says. 
Linds asks how policy decisions may 
be made by tech committee members 
and board members. Jim says that he 
doesn’t think that the node owner can 
do whatever he wants against the 
wishes of the board. Dana said the 
node owner can pull the plug on his 
equipment ifhe doesn’t get satisfaction 
from NEDA, the network, or the 
NEDA technical committee. 

Bob, NQIC, doesn’t think that all 
node owners would have the technical 
expertise to judge the tech committee. 
But even so they still have the ultimate 
veto power. 

Kevin says that as the network 
evolves some people will pull out be- 
cause they don’t like the way things 
have changes or their own position in 
the network. The club is stuck with a 
kind of inertia trying to keep the larg- 
est network possible because we can’t 
please everybody. Bob, WB2QBQ 
mentions that the club was started by 
a bunch of guys who ‘knew a better 
way but that we have to watch the in- 
terpersonal relationships. 

Rich states that the division of the 
network by region is good and that the 
NRS for the region must be left to 
perform his work in that region. 
What’s wrong with non-NEDA 
node op locking in our nodes? 

Herb, WB1DSW, says that some- 
where we should define what’s wrong 
with doing level 3 directly into the 
network from outside by locking in 
nodes. Rich says that the main prob- 
lem is that we don’t know how L3/L4 
works as well as we must before we 
change the existing policy. We don’t 
know as much about G8BPQ and 
MSYS as we do about TheNET. Our 
NRSs still don’t have the capability of 
monitoring traffic on the backbone 
sufficiently to determine abuse. The 
method that the club has defined with 
each station connecting into the net- 
work, then across, then out, keeps us 
safe. Users and servers should uplink 
to the local node, then jump across the 
network or to the destination node. 

Herb asks if our policy is that all 
network users, including servers, are 
supposed to connect to the local node 
first, then across. Rich answered yes. 

Herb asks that if he documents 
another node package sufficiently that 
the NEDA NRS can understand, in- 
terrogate and prove compatible opera- 
tion, then will this new node package 


be acceptable to become a real active 
part of the network? Jim K1MEA says 
that NEDA says no node may be part 
of the network if NEDA doesn’t have 
control. He also listed off a few insta- 
bilities in the G8BPQ software that 
make it a very bad choice at this time. 

Rich asks why a user of a non- 
TheNET node software package 
couldn’t come in via a local port as per 
NEDA recommendations? Herb says 
that there is no problem and it only 
takes one line in the forward file. Jim 
says that the control that NEDA is 
defining is for the betterment of the 
use of the frequencies that we are us- 
ing and the network. NEDA has 
something that we know to work. It 
is not political. Our public relations 
isn’t as good as it needs to be. A lot of 
our technology is based on trial and 
error. We also need some computer 
simulation efforts to see if we can im- 
prove things. Rich says that as time 
goes on we will continue to learn. 

Cal makes a motion that NEDA es- 
tablish a policy that L3/L4 connects to 
inside the network from a non-NEDA 
controlled node are not allowed. Cal 
asks that all stations that have the 
capability of doing L3/L4 across the 
network and are currently doing so be 
asked to stop. 

Dana brings up that a TCP station 
that uses the network would have to 
be part of the network organization 
and controlled by a person participat- 
ing in the technical committee. 

Dana seconds the motion. 

Jim asks if the problem is defined 
correctly. 

Cal says that the only way to limit 
L3/L4 abuse is by mutual agreement 
of all parties or by massive sysopping 
of the network. Dana brings up that 
there may be a solution by modifying 
TheNET to eliminate slime trailing. 

Cal, W1JFP, doesn’t think there’s 
any reason why we can’t tell the indi- 
viduals that are violating the ingress 
rule to stop. Cal thinks that stating 
that we don’t know if it’s bad isn’t a 
problem but that we have to stick to 
our guns. Bob, NQIC agrees and that 
we should specify non-NEDA node in 
the policy and not mention TheNET. 

Dana brings up that the L3/L4 
problem also includes the fact that we 
propagate BBSxxx G8BPQ node 
names in the local regions around 
those boards. Kevin states that Rob, 
KC3BQ, mentioned that problem in 
his notes back in ’89. Dana mentions 


that there would be ‘hell to pay’ if we 
made a policy to turn off that propa- 
gation. Jim says that he likes the 
feature of having BBSMTM show at 
the MTM node. He says that this way 
his users connect to MTM and connect 
to BBSMTM thinking that they are 
going direct over 145.05 when in fact 
they are going by way of 440 through 
the BERK node. 

Dana asks if a BPQ BBS users who 
are doing inbound via the BBSxxx 
should be using NEDA specified 
parms. 

Linds makes an example of the 
change that would be required to make 
this policy. He says that currently a 
user from his area can do C CENTNH, 
C BBSWOK. After this policy is in ef- 
fect the user would have to do C 
CENTNH, C NHOEM, C BBSWOK. 
Cal, W1JFP, says that this is an ex- 
cellent point and withdraws his mo- 
tion. 

Russ, WA1TLN, asks Rich how bad 
the interference with the network from 
a single BPQ node is. 

Jim suggests that the L3/L4 prob- 
lem should be ignored unless it is 
abused by taking greater than fair 
share of network band width. No 
blocks would be inserted in the net- 
work unless there was a cooperation 
problem between the NRS and the L3/ 
L4 external user. Cal brings up that 
the NRS is the pivotal person. Dana 
brings up that only Dana and 
WAITPP are capable of observing the 
problem on their matrix monitors. 

Rich says that our nodes don’t do 
nodes broadcasts so that stations 
would have to do L2 connects into the 
network. Rich thinks that we should 
go with W1JFP’s proposal that we 
don’t allow ingress into the network at 
level 3. Then we decide how to handle 
the justifications for that and how to 
handle the BBSxxx detail at another 
time. Dana agrees and mentions that 
the BBSxxx problem’s are localized by 
design. They only show in the local 
region around the PBBSs. 

Rich restates the proposal that 
NEDA does not allow L3/L4 connec- 
tions from outside the network. Dana 
declares this out of order due to the 
fact that it is presented in the nega- 
tive. Bob, NQIC, restates that L3/L4 
capable sources must come into the 
network by connection to the local 
NEDA control port and then launching 
into the network. 

Linds brings up that the NRS is the 


person who checks out that a new node 
is correctly set up before it is admit- 
ted to the network. NTECH does not 
need to be involved. If the NRS does 
not think that the node meets the re- 
quirements then the NRS should cause 
the node to be gatewayed to. 

L3/L4 connects across the NEDA 
network must originate from NEDA 
approved sources. WA2WNI seconded 
the motion. Passed. 

At this time the meeting recessed 
for lunch at 1:12PM. 

The meeting was reconvened at 
1:50PM. 

Rich brought up that sources want- 
ing to connect across the NEDA net- 
work must connect to the adjacent 
NEDA node first. If a NRS notices that 
this is going on in another NRS’s ter- 
ritory he should contact the NRS local 
to the problem. If a NRS notices that 
this is going on in his own area he 
should contact the person that is 
making the violation. Blocks would 
only be done after the person doesn’t 
disable locked nodes that point inside 
the network. 

Lindsay returns 

After the assurance from all present 
that spoke to Tadd that Tadd is sorry 
that he meddled with Lindsay’s work, 
Lindsay withdrew his resignation. 
L3/LA from outside the network, 
to inside 

Cal discussed how the PBBSs who 
are running G8BPQ were to be in- 
formed of the L3/L4 into the network 
violation now that this motion has 
been passed. Cal says he is trying to 
word it more general than just for 
G8BPQ and PBBSs. Rich suggests 
that he will take care of writing such 
a statement and distributing it. Jim 
suggests that announcing that our 
network may be sabotaged by a G8 
user might cause somebody to do this. 
Jim mentions that anti-NEDA hate 
mail is carried very efficiently by the 
NEDA network (laughs). 

Cal, who has been making notes, 
states “Resolved that all outside 
sources be required to first connect to 
the adjacent NEDA node before con- 
necting on in the network. This action 
is necessary to insure that the network 
resources are equally shared.” 
K1MEA seconds: passed. 

DxCluster user abuse 

Dana says that the installation of 
extra DxCluster systems accessible 
from the network has eliminate the 
previously observed abuses. Users no 


longer feel the need to connect the 
length of the network to obtain Dx 
spotting information. 

Rich mentions that he read that the 
G8BPQ code supports DxCluster now. 
Cal recommends that this not be rec- 
ommended as the problems we're al- 
ready having with PBBSs using G8 are 
bad enough. 

BBSxxx nodes propagation 

Kevin makes a motion that we not 
allow any more G8BPQ/MSYS etce.. 
BBSs to propagate even in the local 
region, outside its local node cluster 
until the problems associated with this 
are resolved. WB2JLR seconds. 
Passed. 

Chairman of board meetings 

Rich brings up the agenda item that 
there might want to be a constant 
board meeting chairman. Dana re- 
minds us that at one time this was 
discussed and that the previous board 
meeting chairman would serve until 
the next board meeting. Cal, W1JFP, 
reads “It would appear that it would 
be appropriate to have a permanent 
board chairman to act on matters that 
required coordination between meet- 
ings. The selected leader could chair 
the meetings but need not necessarily 
do so if the group prefers otherwise. 
Most organizations have a person at 
the head. This head would be chosen 
by the board members as opposed to 
the more formal arrangement of voting 
in the position at the annual meeting” 

Dana nominates Cal, W1JFP, for 
that position. Rich seconds. passed. 

Cal moves that Rich Place, 
WB2JLR, is nominated for vice chair- 
man. Dana seconds. Passed. 
Location for next meeting 

Rich mentions that Don Russ, 
N2CZL, has suggested Oneonta as a 
good place for one and has volunteered 
a location. The date was presented as 
July 27th. Cal made this a motion. 
Rich seconds: passed. 

Second Class Mailing Permit 

Herb Salls, WB1DSW, reviewed the 
questions of “what is a second class 
permit?”, “what does it take to get 
one?”, “what does it do for us?”, “what 
does this do to advertising?”, “How 
slow will the mail be?” etc... It was 
decided that there would be a one or 
two day delay maximum between the 
service that we have been getting and 
the 2nd class permit. We can classify 
for 2nd class as a non-profit organiza- 
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tion. There will be an overwhelming 
savings in our mail costs. The last 
Quarterly mailing of 250 booklets was 
$302.50. That’s about $1.21/piece. If you 
mail second class, there is a $275 one time 
fee. If we divided that over 4 quarters 
and at 14.2 cents/pound (x250 = $9.18) 
for a total of $77.93 to mail out 250 
Quarterlies. 

At this time the fire alarms went wild 
for several minutes and rendered all 
present deaf. Firemen ran through the 
room. Mayhem commenced. It was 
pretty bad. 

Herb says “Thank you Mr. Bell. Much 
appreciate that” 

So it is much cheaper. It would also 
be much easier to mail it. No more lick- 
ing of stamps as we could use a rubber 
stamp to print our second class mail 
permit number on the envelope. [Amid 
the noise of fire trucks leaving] There is 
a sorting requirement but with the com- 
puter this is pretty trivial. Herb says that 
he has to mail the Quarterlies from East 
Kingston to meet the requirements of a 
‘known office of publication’ which should 
be at Herb’s house for convenience. Oth- 
erwise we'd have to rent an office or 
something. This is where an annual au- 
dit is performed. Herb can only drop off 
the Quarterlies on Saturday as the East 
Kingston post office closes on weekdays 
before he gets home. The ‘known office 
of publication’ is transferable for a fee. 
We also should put money on deposit so 
we can use the permit number. Herb 
recommends $100. 

Dana asks what the nature of the au- 
dit is. Herb says that the postal official 
would look at the mailing list and paper 
documentation that we have to back up 
the computer mailing list. The postal of- 
ficial would make sure that the newslet- 
ter is what we are billing it as and that 
there isn’t more advertising in the news- 
letter than we are saying there is. Dana 
and Herb discussed the funds that we’d 
have to spend to mail a newsletter that 
does have advertising. The amount ap- 
pears to be trivial and we could definitely 
afford to do advertising. 

NQIC remarks that the permit num- 
ber can also be used for first class for 
convenience. Herb, WB1DSW,, says that 
he hasn’t heard this be hel find out. 

Cal, W1JFP, asks if Herb minds the 
inconvenience of having the audit done. 
Herb says that hel work the timing out 
with the Manchester post office. Cal, 
WA1WOK, remarks that he can get 1 or 
2 volunteers to help Herb with mailing. 


NQIC mentions that the delays that 
HCRA has with mailing is higher for local 
mailing. 

[fire trucks return] 

Herb also requests that NEDA invest 
in the Domestic Mail Manual @ $24.95 
from the Government Printing Office. 
Also he wants to purchase a $15 rubber 
stamp with our second class permit on 
it. 

Dana Jonas, WA2WNI makes a mo- 
tion that we authorize Herb Salls up to 
$390 to get the second class mailing per- 
mit started. Cal, W1JFP, seconds it. 
Passed. Herb says that he1l have it in 
the mail on Monday. 

Frequency Coordination 

Skipped over 
NEDA Official Bulletin format 

Dana says that he hasn’t worked this 
up yet and it should be skipped. Jim 
K1MEA, brings up that it is difficult to 
determine from NTECH/NBOD mail 
what is discussion and what is official 
ruling. When a ruling is determined it 
should be logged somewhere as well, Jim 
adds. This is postponed to the next 
meeting. 

WB6RDH Bulletin board funding 

NQIC talks about this mentioning 
that he’s gotten lots of good stuff that has 
benefited NEDA and the BBS ops. 

Rich, WB2JLR says that if NEDA 
supports WB6RDH's board then wouldn't 
other people wonder why NEDA doesn’t 
support them. 

Dana recommends that editor puts 
something in the next Quarterly giving 
information on the WB6RDH board and 
suggesting that NEDA likes the activi- 
ties of this board and that individuals 
could support it. NQ1C should write this 
article and send it to Tadd to be included 
in the Quarterly. 

Club membership 

Is it reasonable to have a club affilia- 
tion membership? 

Herb, WB1DSW, stated that NEPRA 
has joined as an affiliated club at the $100 
rate but it appears that there are other 
clubs that join at the $15 and $25 rate. 
Why is this? 

Cal makes a motion that the $100 
membership is discontinued and that the 
difference between that membership and 
the $25 voting membership be refunded 
to any clubs that have joined at that rate. 
K1MEA seconds it. 

Dana reads from the January 1990 
board meeting minutes. Dana states that 
the Affiliated club gets copies of the new 
documentation as soon as it is produced 
and they get space in the Quarterly and 


in the Annual for every issue Herb, 
WB1DSW,, asks if Joe Schmoe’s Dx Soci- 
ety wouldn’t get the same service if they 
sent an ad. Dana states that the editor 
might not print it or could edit it down. 
Herb doesn’t see $75 difference. Jim is 
against this concept because it is insulting 
to ask a club that has already put $1000s 
of dollars into the network to join NEDA 
at $100. 

Someone asks if NEPRA’s advertise- 
ment in the Quarterly would violate the 
second class permit agreement that we 
want. Herb says no as NEPRA’s add isn’t 
for profit either. 

Dana asks if a club that joins with a 
$25 membership level can re-assign the 
person that attends meetings. This was 
a benefit of the club affiliation member- 
ship. 

Rich amends the motion to state that 
instead of eliminating the club member- 
ship it would be reduced in cost to $25. : 


Linds asks what happens with the 
$75. Cal and Rich believe that the money 
should be refunded. 

Jim brings up that people who are 
members of a club that is affiliated with 
NEDA might think that they shouldn’t 
join NEDA as well. Herb says that this 
was a reason for the high $100 fee in the 
first place. Cal thinks that the fact that 
they get their very own Quarterly should 
be enough. 

Constitution Revision 

Should the Constitution be revised to 
provide for written ballet by mail to elect 
board members with the result being 
announced at the general meeting. This 
would provide for the general meeting 
being strictly show and tell. 

Jim says that “Tadd felt that he’d like 
to see the general meeting should become 
basically a show and tell.” It seems to 
me that we’d get greater participation 
with mailed ballets. Rich says that a lot 
of people can’t make it to the general 
meeting. Linds asks if the timing is cor- 
rect so that the ballet can be included in 
the Fall Quarterly. This would send 
ballets to everybody, voting or non-voting 
but only eligible to voting members. [The 
written submission of this is printed 
elsewhere in this issue] 

Resource Manual, funds for 

Dana shows the NEDA Resource 
manual which he says was created in a 
hurry. The document was made for pro- 
motion for NEDA, Dana says. He wants 
to do another printing of the book which 
is running out pretty quick. Dana points 
out that we've already gotten several new 
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memberships because of the manual. We 
probably turn a profit on it and it also 
prompts potential node ops. Herb, 
WB1DSW, agrees that we get a flurry of 
new members when we create new 
documents and distribute them. Dana 
presents a $102 bill for 100 copies of the 
manual]. Dana moves that the bill is paid 
for this. Dana also would like to make 
200 more copies after some subtle revi- 
sions are made. The printer would bill 
the treasurer after the 200 copies were 
done. Dana would like reimbursement 
for the $102 immediately. The question 
as to whether funds should be charged 
for the document was raised and after 
discussion decided against. Jim brings 
up that documentation is what we give 
the members for their money so let’s 
make it free. 

Linds suggests that this might be a 
document that could be given in place of 
the GANI to a non-informed person ask- 
ing about node implementation. 

Dana says that the resource manual 
was a highly edited version of the origi- 
nal document by NJ7P. Tadd and Dana 
wrote about half of the information in the 
manual. The information in the manual 
is based on NEDA design philosophy. 
Dana proposes that maybe the informa- 
tion might be incorporated into the An- 
nual Membership Package. Dana sug- 
gests that we might want to ship the 
manual with a floppy disk. 

Jim asks if TN2.08B is the software 
of choice. Dana says yes because of the 
Heard list, better routing table list, better 
controllability of ports, including the 
ability to stop propagation of nodes 
through any node using the R 2 and R 3 
commands. This may also be used to se- 
lectively stop use of the system by abus- 
ers. Jim brings up that TN2.08 has been 
used badly elsewhere because of this 
feature. 

Dana also asks for funds to purchase 
floppy disks. He estimates $28 to pur- 
chase 100 floppies. 

Cal suggests that $228 be allocated to 
purchase the previously described mate- 
rials. Dana says it would take $300. Cal 
restates that $328 should be allocated. 

The subject is changed briefly to talk 
about other documentation requirements 
against the current low value of the 
treasury. Hexipus documentation is 
briefly discussed. Rich says that the 
Hexipus documentation is written but not 
published. 

Dana moves that $102 be appropri- 
ated to refund his purchase of 100 blue 
resource manuals. Seconded: passed 


Dana asks if a better deal exists for 
the 5 1/4" floppies. Rich asks how many 
of the first 100 books are left. Dana 
guesses 35. Rich suggests that maybe if 
we made 200 more that 2.09 might come 
out before we get rid of 200. Dana sug- 
gests that they can be gotten rid of very 
easily at Dayton, Rochester and Deer- 
field. Dana points out that the back page 
has a membership application. Linds 
recommends that at $1 per piece that 
they should be reserved for technical de- 
velopment sessions. Dana says that what 
Tadd, he and Bob WB2QBQ, have been 
doing is running to hamfests and mak- 
ing personal contact with people who are 
highly motivated to do networking in 
packet radio and then to entice those 
specific people to get them going by giv- 
ing them documentation and software. 
Dana suggests that also Quarterlies 
might also be required. Herb, WB1DSW, 
mentions that he has some extra Quar- 
terlies as well so Quarterlies won’t be 
required. 

Kevin, WA2VAM, brings up that the 
document says NEDA on it but he wants 
to know who approved it. Kevin speaks 
strongly against individuals producing 
documents or products in NEDA’s name 
or expecting NEDA funding without prior 
board of directors authorization. Kevin 
wants a motion made such that the board 
of directors has more of a control of the 
content of documents that have the 
NEDA name on them. Kevin says that 
as a board member he will vote against 
funding any item or documentation that 
was created without prior board of direc- 
tors authorization. 

Jim calls a point of order to bring us 
back to Dana’s motion about funding for 
more Resource Manuals. The question 
is how much money should Dana spend 
on disks. Fred, N1EZD, says that he'll 
donate 50 floppies. (claps) 

Kevin suggests for a motion that fur- 
ther publications or projects must have 
prior approval. Kevin brings up that the 
resource manual has not been seen before 
by the chairman of the technical com- 
mittee. 

Kevin moves that all publications or 
projects or information dispersal that is 
intended to be represented as NEDA 
material needs prior approval before they 
can be produced. Linds seconds: passed. 
Quarterly Newsletter 

Dana moves that we allocate $100 to 
spend on mailing expense for the coming 
Quarterly. Rich seconds: passed 

Last quarter printing we had 500+ 
Quarterlies made for $335. 


** At this time Jim, K1MEA and Bob, 
NQIC leave ** 

There is still a quorum with 
WA2VAM, WA2WNI, WB2JLR, NRIN, 
W1JFP. 

Conversation occurs about the large 
number of Quarterlies that were printed. 
The consensus is that it is to our advan- 
tage to have extras printed. Lindsay says 
that we are spending $600 per year for 
extra Quarterlies. Herb says that we 
can’t accurately predict how many 
Quarterlies we are going to need. Our 
printer would feel abused if we keep going 
back for more copies. Cal makes a motion 
that we appropriate the sum of $335 to 
print Quarterlies for the Spring quarter. 
Dana seconds: passed. 

Cal states that we have $782 in the 
treasury at that point. 

Purchasing of Modems for research 

Consensus is that there should be no 
investment in modem hardware at this 
time. 

Freebees, funding for 

Dana brings up that the current free- 
bee is as much better than the previous 
freebee as our current Quarterly is over 
the Quarterly of a few quarters ago. 

Herb mentions that the previous 
freebee cost $63 for 300 of them at a 
quickie print shop. Rich, WB2JLR, 
makes a motion that we authorize $100 
to print freebees and that the board of 
directors will have to approve it first. 
WA2WNI seconded: passed 
Funding for promotional events 

Rich wants to know if anybody has a 
specific need for funding for a flea market 
table. Rochester is free. Dana suggests 
that last year we had funding available 
and that it was nice to have it around 
even though nobody drew on it. The item 
was dropped. 

Funding for Hexipus Advertising 

Cal says that somebody was going to 
do a magazine advertisement. Rich says 
that we would have a magazine review 
that wouldn’t cost us. 

Resource Manuals, funding for 

Dana makes a motion that pending 
approval of the board for the document 
that we allocated up to $200 for produc- 
tion of the technical resource documen- 
tation. Rich states that the Quarterly 
might be a good enough handout that the 
Resource Manual and the disk might be 
unnecessary. Linds states that the only 
person who would need the Resource 
Manual would be someone who had 
$3000 to spend on anode. Rich suggests 
that we amend the motion to be $100. 

Continued on page 35 
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SERVERs Accessible From The NEDA Network 


The following is a list of PBBS’s that 
can be reached from the NEDA net- 
work. The list was compiled from for- 
warding files that were submitted to 
me through 26 Jan 91. Some paths 
have nodes that are not part of the 
NEDA network. I have tried to provide 
the best path from inside the NEDA 
system. Please consult the “BBS Op- 
eration” section in the membership 
package for information on interpret- 
ing this table. Some of the paths list 
here may be a little rough. Some of 
the paths have been replaced by bet- 


ter ones since this list was compiled. 
Please keep in mind that in packet 
radio, change is the rule (much like 
other branches of amateur radio). 

Note: Do NOT forward 3rd party 
traffic long haul. It might be nice to 
send traffic that is destined for a PBBS 
direct to that PBBS but there is no 
reason to do long haul forwarding of 
bulletins and traffic that you can’t 
route to it’s final destination! 

The first nodename in each connect 
path is a NEDA network port that is 
propagated. Other nodenames may be 


PBBS, non NEDA nodes or local ports 

on NEDA nodes. 

Class 1: wireline from NEDA node 

Class 2: direct from 220 or 440 NEDA 
port 

Class 3: multi hop from NEDA node 
via non 2meter links 

Class 4: direct connect from 2m or HF 
NEDA user port. 

Class 5: digipeater or multi-hop over 
2m or HF from a NEDA user port. 

—Jim, KIMEA 

BBS Committee Chairman 


PBBS servers 
call path Class Member? NODEcmptbl? notes 
klacl kngil11,k1lacl 2 n n rochester nh 
nlapi _chstr,berk,connct,n1dcs-2,nlapi-4 3 n n meriden ct 
ke2az _— elmira, bbsaz,kc2az 5 n y elmira ny 
nlbgg kngl11,mbos,c 3 nlbgg 3 n y charlestown ma 
kicf nshr22 kicf 2 n chelsea ma 
wb2coy clv440,bbscoy 2 y y poughkeepsie ny 
nldes__chstr,berk,connct,n1ldes-2,n1dcs-4 3 n n new haven conn 
wbldsw kng111,bbsdsw 1 y y goffstown nh 
wleoo _ chstr,berk,connct,icrc07,wleoo-1 5 n n winstead ct 
walfhb swnh,walfhb 5 n n marlow nh 
wlfyr swnhu,wlfyr-1 (aplink + BBS ) 2 y n gilsum nh 
kalgoz snh,bbsgoz 2 y y nashua nh 
waliie kng1l11,mbos,lew,waliie 5 n n vassailboro me 
kqlk kng111,mbos,scit,kqlk 3 n n dennis ma 
klmea_chstr,klmea-4 2 y y easthampton ma 
kalmgo snh,bbsmgo 5 n y methuen ma 
nsln kng111,mbos,scit,ns1n 3 y y scituate ma 
kb4n _— snhuhf,bbsash 2 n y nashua nh 
wlny  spfld,bbswma 1 y y springfield ma 
wlops_ chstr,berk,connct,kaljes-12,wlops-13,wlops-1 5 n n waterford ct 
kalpep nshr22,kalpep 2 n y lawrence ma 
walphy kngl111,mbos,bbsphy 3 y y mitre arc bedford ma 
kblpj  snhuhf,kblpj  (aplink) 5 y n amherst nh 
wa2pvv knd220,Net40 2 y y valatie ny 
wb2qja_chstr,berk,connct,wb2zii-9,wb2qja-4 5 n n white plains ny 
kalrci kngl11,mbos,pvd,kalrci 3 n n lincoln ri 
w2rgi _ stmfrd,w2rgi (chk w/sysop for fwd window) 4 n n oneota ny 
wa2rkn wma220,eny2,wa2rkn-2 5 n y poughkeepsie ny 
k8rli elmira,bbsaz,elm220,k8rli v k3rli-2 3 n n wilkes-barre pa 
kirqg kngl11,mbos,mwu,kirqg-1,klrqg 3 n n bucksport me 
wa2sna_berk,connct,kglo-9,nnj3,wa2sna-1 5 n n hawthorn nj 
kalsrd_ snh,bbssrd 4 n y fitchburg ma 
wa2tve utica,wa2tve-4 2 y y utica ny 
klugm kngl11,bbsugm 2 y n wakefield ma 
wa2umx albny3,srtoga,wa2umx 2 y n saratoga ny 
kluol —clv,k1uol 4 n n bethel ct 
walwok nhoem1,bbswok 1 y y nhocm concord nh 
wb2wxq candga,candga2,wa2wxq 2 n n rochester ny 
DOSGate 
call path Class Member? NODEcmptbl? notes 
nmld = snh,nm1d-2 (dosgate /r callbook ) & n n derry nh 
wb4hfn mtunc,wb4hfn 2 n n ie 

Continued on next page 
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DxClusters 


call path Class Member? NODE cmptbl? notes 

klea ycccdx,klea 2 n n harvard ma 
k2tr dxknox,k2tr 2 y n knox county ny (albany) 
wa2tve dxclus,wa2tve-2 2 y n utica ny 
w2hpf monroe,rdxa,w2hjf 2 y n rochester ny 
Other 

call path Class Member? NODE cmptbl? notes 

wdly _ nhoem1,nhnet,wdlv (CD ROM callbook) 5 n n manchester.nh 
klbpm _ nshr22,klbpm 2 n y peabody ma 
<< Please report any bad information or changes to NEDA @ WINY. Title >> 

<< it “Attn.: BBS Committee”. Otherwise itl still be bad in the next issue! >> 

<< Acurrent machine readable version of this table is available for download >> 


<< from the KIMEA BBS under the file section NEDA. >> 


Minutes from page 33 

Lindsay submits that the few copies that 
we have left should be enough to give to 
existing sysops. Dana brings up the con- 
cept of selling it again. Kevin says that 
if they want it bad enough to pay for the 
mailing of it then we should give it to 
them. Herb guesses that it will cost us 
65 cents to mail it. Dana suggests include 
a disk and sell it for $3 including mailing. 
Cal says that it would save a lot of hassle 
if we just swallowed the expense and gave 
it out for nothing if we were discriminate. 
Linds and Rich decide that the fewer 
copies that we have the more discrimi- 
nate we will be. Rich says that we won’t 
have another 200 new NEDA nodes in 
some unmentioned period of time. 

Dana thinks that we are pinching 
pennies. He is looking for $200 still. The 
board of directors will still have approval 
at any time to spend from that kitty. 
Kevin seconds: passed with 3 for, Cal ab- 
stained and Kevin against. 

STMFRD upgrade 

Kevin and Jim want to acquire 
funds from private individuals and 
clubs to fund a speed improvement for 
the STMFRD-> CHSTR link. 

Dana brings up the Tadd pipe- 
dream of a 56KB network. [Lots of in- 
teresting pipe whistles in the back- 
ground]. Kevin seems taken aback. 
Cal comments that if this project is far 
enough forward to supplant proven 
technology (9600 baud) that he would 
like to have been informed earlier. 
Dana says that it isn’t past the mad- 
scheme stage. 

Someone in the audience suggests that 
the agenda for future meetings be or- 
dered so that appropriations are at the 
top of New Business and Old Business. 
Cal and Dana agree. 

Kevin, WA2VAM leaves. 
W1JFP, WA2WNI, NRIN, WB2JLR 


Canadian Membership 

Herb, WB1DSW says that Cana- 
dian checks cost $5 per check to deposit 
so Canadian members must add $5 
American to their membership which 
must already be in American funds. 
Cal suggests that we might want to get 
a Canadian POBox such that Cana- 
dian funds may be filtered to reduce 
the number of funds transfer. 

Dana makes a motion that an addi- 
tional $5 (American) assessment be 
made for all Canadian checks: 
WB2JLR seconded: passed 
Board Member Alternates 

Dana asks that Bob, WB2QBQ be 
appointed his alternate. Bob is node 
owner/operator of KNOX node and part 
owner of CHERRY. Passed 
General Meeting 

Rich asks if anybody has objection to 
holding the general meeting the same 
weekend as the fall quarterly board 
meeting. Linds suggests that we might 
want to have 3 or 4 simultaneous regional 
meetings instead. Tabled Cal asks if we 
want to delete the requirement for the 
annual meeting. Linds says yes. Cal 
suggests that we delete the requirement 
for the annual meeting. Copies of Cal’s 
recommendation and hand written 6 
times. 

Hexipus Consignments 

Cal provides a sample consignment 
document. The document has instruc- 
tions which describes its purpose. [See 
reduced copy elsewhere in this Quarterly] 
Dana suggests that we can’t do this 
business over packet. Cal says he'l revise 
the document to delete the comments 
about doing it over amateur radio. Phone 
or US mail will be used. Dana thinks it’s 
really good. Linds moves that we approve 
it. Rich seconds. Approved. Cal says he’l 
ship it to Howie. Dana says he'll make 
his own copies. 


Chairman of next board meeting 

Lindsay suggests that Cal should be 
the default meeting chairman unless it 
is brought up otherwise at another time. 
Cal says that he'll continue to do the 
agenda. 

220 band and coordination 

Dana mentions that the Upper New 
York REPeater COuncil was discussing 
220 at it’s last meeting. He asks what 
critical links NEDA has below 222Mhz. 
Linds mentions VNH-CENTNH-SWNH 
on 220.55. Dana says that links in East- 
ern NY that are below 222 are moving to 
low power 440 links. Dana tells us that 
in Eastern NY approval has been granted 
by UNYRepCo to allow 440 splinter fre- 
quencies (12.5Khz frequencies) to be used 
for low power point to point links running 
less than 5 watts and directional anten- 
nas with 3Khz or less deviation. Dana 
recommends that Linds suggest to 
NESMC that they allow this as well. 
UNYRepCo also approved new 2m fre- 
quencies for packet usage. This specifies 
low power 10 watt ERP, non-elevated lo- 
cations on 147.42 435, 45, 465 and 48. 
This allows packet channels to be added 
to sites that already have packet sites on 
the low end of the 2m band. This allows 
for true cellularization of packet LANs. 
6 meters + NH nodes 

Dana brings up that WB2QBQ and 
he are looking into putting up a link 
between NH and NY through lower 
Vermont. 6 meters is being consid- 
ered. 

Cal brings up that every location in 
his area seems to be full. Cal says that 
he can’t accommodate another port at 
SWNH or VNH. 

Rich makes a motion that we ad- 
journ the meeting. Cal seconds: meet- 
ing closed at 4:51PM. 

—WA2WNI 
—NEDA Secratary 


remain so Quorum still exists 
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Membership Roster as of 6/10/91 - 244 members 


callsign 
VE3ABG 


last name first 
Caberlin Joe 
Schenectady ARA 
Bullett Charles 
Cannan Frank 
Dawson Earl 
Buckwalter Stan 
Sullivan Jim 
Leslie Jim 
Piggot Charles 
Johnson Arnold 
King Jay 
Wenskus James 
Lang Burt 
Smith Tim 
Altpeter Paul 
Sadowski Edward 
Lafleur Bob 
Peterson John 
Garratt Barry 
Griffin Dennis 
Stampf Charles 
Cui Dan 
Farrell Robert 
Barry Bob 
Abel Jack 
Farr Well 
Henderson Leon 
Russ Donald 
Hitz George 
Baker Raymond 
Clark Donald 
Timmins William 
Torborg Tadd 
Baker Brian 
Walter Ronald 
Howarth Robert 
Donah Dennis 
Schmarder David 
Clark Jim 
New Englnd Packet RA 
Salls Herb 
Unverhau David 
Everitt Doug 
Cupp Fred 
Wilson Dave 
Seastream Robert 
Stull Harold 
Wollf Ken 
Tilley David 
Sluymer John 
Elliott Edward 
Lilly Randy 
Clark Albert 
Donaldson Fred 
Lundholm Don 
Swiatlowski Fred 
Ward James 
Bassett Doug 
Taylor Dave 


city 
Willowdale 
Scotia 
Auburn 
Livermore 
Enfield 
Briarwood 
Woburn 
DDO 
Medford 
N. Swanzey 
Rochester 
Rochester 


Mattapoisett 
Victor 
Coventry 
Springfield 
Augusta 
Ontario 
Orchard Park 
Lagrangville 
Barrington 
Poughkeepsie 
Nashua 
Albany 
Cntrl Bridge 
Wht Riv Jct 
Bainbridge 
Sudbury 
Depew 

W. Newbury 
Warren 
Potsdam 
Depew 
Liverpool 
Lisbon 
Hudson 
Beaver Dams 
N.Plainfield 
Needham 

E. Kingston 
Schenectady 
Boulder 
Fairport 

E. Burke 
Long Valley 
Corning 
Harvard 
Lancaster 
Grassie 
Shortsville 
Allentown 
Phoenix 
Templeton 
Durham 
Oswego 
Nichols 
Greenfield 
Belchertown 


home BBS 


VE30Y 


- WA2UMX 


WA10JB 


K1MEA 
K2APL 
VE2FKB 
WB2WXQ 
WI1FYR 
WB2PSI 
WB2WXQ 


VE2FKB 
WAIPHY 


KAI1RCI 
WINY 


W20Y 
WB2COY 
WB1DSW 
WB2COY 
KB4N 
KB2CS 
WA2WNI 


W2RGI 
K1UGM 
W20Y 
WI1FYR 
KA2JXI 
N2CVQ 
CNYBBS 
WA1DPP 
WB1DSW 
KC2AZ 
KB4CYC 
WB1DSW 
WB1DSW 
WA2UMX 


WB2WXQ 
N4DW 
N2ELC 
KC2AZ 


exp mem 
9205 Q 
9201 V 
9106 Q 
9108 V 
9203 Q 
9205 Q 
9107 Q 
9203 Q 
9202 V 
9105 S 
9205 Q 
9105 Q 
9112 Q 
9110 Q 
9201 Q 
9203 Q 
9111 V 
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Koopman 
Rudenauer 
Leuthold 
Celone 
Hansen 
Niebuhr 
Kenney 
Cooley 
Obrien 
Dillaby 
Ferguson 
Ovad 
Swanburg 
Merril 
Rappaport 
Leach 


Csernelabics 


Karpinsky 
Goble 
Robinson 
Holmer 
Gorman 
Brayman 
Morrissey 
Graziano 
George 
Oldenburg 
Heavener 
Wright 
Hathaway 
Phillips 
Baltradis 
Centanni 
Siegel 
Rotolo 
Preston 
Fernandez 
Syvertsen 
Read 
Phillips 
Engman 
Harris 
Raposo 


Collinsworth 


Stiles 
Svalland 
King 

Place 
Ousterhout 
Johnson 
Werren 
Schnitchler 


George 
William 
F. X. 
Brian 


Robert 


Ike 


Franklin 
Melvin 


city 
Windham 
New Ashford 
Manchester 
Rochester 
Spencer 
Chicopee 
Gilsum 
Hingham 
Glens Falls 
Acton 
Waterford 
Thomaston 
Elmira 
Lockwood 
Toms River 
Etna 

Reo Linda 
Nashua 
Granby 
Blairstown 
Atkinson 
Goffstown 
Colebrook 
Hudson 
Portsmouth 
Otego 
Schenectady 
Tyngsboro 
Acton 
Vestal 
Unadilla 
Summit 
Portsmouth 
Sanford 
Tonawanda 
Erie 

E. Freetown 
Syracuse 
Geneva 
Potsdam 
Fairport 
Derry 
RiverDale 
Massena 
Ogdensburg 
Albany 
Berlin 

Midl Grove 
Warren 
Webster 
Holland Ptnt 
Jodus Point 
Hanover 
Kingston 
Cobleskill 
Canandigua 
Ogdensburg 
Bristol 
Sherman 
Binghamton 


acct oe Bo Be Bae 8 ooo Bo Be Bd 


home BBS’) expmem 
KB4N 9203 S 
WA2UMX = 9112. Q 
WAI1WOK 9105 Q 
- 9205 Q 
WF2A 9111 Q 
KIMEA 9204S 
W1FYR 9105 V 
NS1N 9112 Q 
WA2UMX = 9107S 
- 9106 Q 
NM3G 9111Q 
N1DCS 9203 Q 
KC2AZ 9202 V 
KC2AZ 9204 Q 
NN2Z 9112 Q 
WI1FYR 9111 Q 
FILL 9112 Q 
KA1GOZ 9202 Q 
WINY 9108 Q 
N2ELC 9110 V 
WB1DSW_s 9108 Q 
WB1DSW =e 9303 Q 
UNK 9202 Q 
KA1GOZ 9204 Q 
WB1IDSW_~s 9111 Q 
W2RGI 9203 Q 
WA2UMX 9201Q 
WAIPHY 9107V 
- 9108S 
WF2A 9204 Q 
W2RGI 9205 Q 
WA2UMX 9105 Q 
WB1DSW~s 9111 Q 
WB1DSW se: 9203 Q 
~ 9112 V 
NM3G 9111 Q 
W2RGI 9105 V 
WA2TVE 9204 V 
WB2WXQ = 9201 Q 
KA2JXI 9106 Q 
WB2WXQ =: 9205 Q 
N11GAL 9205 V 
KD6TH 9205 V 
KA2JXI 9111 Q 
KA2JXI1 9111 Q 
WA2UMX 9201 Q 
- 9205 V 
WA2UMX 9203 Q 
KA3SFC 9111 Q 
WB2WXQ 9105 V 
WA2TVE 9105 Q 
WB2WXQ- 9105 V 
WIFYR 9301 V 
WB2COY 9203 V 
: 9205 Q 
- 9302 V 
KA2JXI 9110 Q 
WAIFHB 9202S 
WAOPTV 9205 V 
WF2A 9105 Q 
Continued on Page 38 
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Roster from page 37 


callsign 
WN2K 
N2KNV 
N2KOP 
N2KPR 
KB2KRB 
N2KTM 


last name first 
Brayman Unatego RC 
Jansen Lew 
Perkins Clint 
Kennedy Terry 
Savini Paul 
Faux Dr James 
Stonehill Judith 
Coyne Ken 
Dresser Ken 
Reynolds Lee 
Aldrich Roland 
Reynolds George 
Gubernard John 
Kean Victor 
Grebus Gary 
Nobrega Julio 
Gauvin Hervey 
Seppala EJ 
Chimel Robert 
Townsend Joseph 
Zuckerman Larry 
Howe Dexter 
Gehret Reg 
Wzorek James 
Hughes Don 
Parker Matt 
Blowney John 
Jolda Joseph 
Fedder William 
Baker Jim 
Kramer Ron 
Mathewson Thomas 
Prentice James 
Dietrich Harry 
Collins Lindsay 
Smith Earl 
Painter John 
Boudreau Joseph 
Meth Eric 
Schaps Robert 
Handley Eric, 
Farnsworth Dave 
Voorhees Denny 
McCarthy Brian 
Horn Andy 
Glassbrook Robert 
Calvete Thomas 
Guro Roy 
Eddy Chan 
Sinclair Ronald 
Hunter Bob 
Slack Bill 
Weirbach Ken 
Speltz David 
Ames Thomas 
Staines Michael 
Castellano Cosmo 
Burningham John 
West Isle ARC 

Cedrone Jim 


city 

Otego 

Ithaca 
Ithaca 
Milford 
Amherst 
Brockport 
Honeoye Fs 
Pine Island 
Johnson City 
Greenville 
Springfield 
Penfield 
Bergenfeield 
Columbus 
Brookline 
Burlington 
Penfield 
Fairvieee 
Clarks Sumit 
Painesville 
Easton 
Bradford 
Bath 
Easthmapton 
Harvard 
Colton 

York Harbor 
Webster 
Sanbron 
West Monroe 
Port Colborn 
Norwich 
Canton 
Elmira 
Washington 
York 
NoKansas Cty 
Fiskdale 
Scarboro 
Scarsdale 
N.Clarendon 
McConlesvill 
Savre 

Vestal 
Bangor 
Bowdoinham 
Rochester 
Springfield 
Concord 
Epping 
Rochester 
Sparta 
Bethleham 
Arlington 
Beverly Frms 
Rochester 
New Hartford 
Mahopag 
Dorval 

S. Boston 


SLLEELLEELEELLS: 


NH 


42552554 


e) 
Zz 


S465 23 CSeSShaees 


home BBS 
W2RGI 
KC2AZ 


- W2RGI 


W2SEX 


WA2RKN 
KK4L 
KB4N 
WA1WOK 
W2FMN 
W8CQK 
WA1PHY 


NM3G 
K3RLI 
WA8BXN 


WA1WOK 
KC2AZ 
KIMEA 
WA1PHY 
WB2JXI 
WB1DSW 
K1IMUJ 
UNK 


VE3SNP 
KA2MYD 
KA2JXI1 
KC2AZ 
WA1WOK 
WB1DSW 


W1BIM 
VE3NUU 


WA1WOK 
WB1DSW 
WB2WXQ 
N2ELC 


KB1PJ 
WB1DSW 
KAINNN 
WA2TVE 
VE2FKB 
WB1AES 


exp mem 
9112 Q 
9111 Q 
9203 Q 
9204 V 
9204 Q 
9201 V 
9205 V 
9106 Q 
9205 V 
9202 Q 
9112 Q 
9111 Q 
9106 Q 
9107 Q 
9112 Q 
9111 Q 
9203 Q 
9203 Q 
9202 Q 
9107 Q 
9107 Q 
9203 V 
9205 Q 
9111 V 
9112 Q 
9203 V 
9111 Q 
9111 Q 
9212 Q 
9108 Q 
9205 V 
9108 V 
9111S 
9204 Q 
9212 V 
9204 Q 
9204 V 
9203 V 
9111 V 
9204 Q 
9110 Q 
9106 V 
9204 V 
9302 V 
9108 Q 
9106 Q 
9107S 
9204 Q 
9105 V 
9106 V 
9205 V 
9205 V 
9107 Q 
9105 V 
9201 V 
9205 V 
9108 Q 
9204 V 
9203 Q 
9105 V 
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NONE 


Membership Roster prepared by WB1DSW — Membership Director 


last name 
Seger 
Chauvin 
Frisone 
Stetson 


Boyle 
Ellsworth 
Garon 
Anderson 
Walter 
Knight 
Moseley 
Warren 
Frazier 
Montgomery 
Vangel 
Garrison 
McAllister 
Malner 
Batik 
Pigott 
Perley 
Parsons 
Cohen 
Varga 
Sencabaugh 
King 
Bogdan 
Morris 
Reiter 
McKnight 
Weiman 
Funk 
Seney 
Wright 
Scanandoah 
Dimilla Jr 
Lievense 
Reichert 
Dombert 
White 
Douillard 
Britton 
Jonas 
Stuart 
Neff 
Stinner 
Packard 
Zanghi 
McCambridge 
Peachman 
Khoury 
Sonsoucie 
Sumski 
McCoy 
Dalton 


first 
Robert 
Paul 
Frank 
Ralph 
Chris 
Blanchard 
Don 
Gordon 
James 
Jack 
Joseph 
Lloyd 
Chris 
Philip 
Irv 
Frank 
Robin 
Schley 
Phil 
John 
Mathew 
Karen 
Russell 
Juergen 
Jerome 


Thomas 
William 
Robert 
Rick 
Jim 
William 
Jim 
Don 
Andrew 
John 
Kevin 
Alan 
Thomas 
Richard 
Leigh 
Ed 
James 
Ronald 
Mike 
Dana 
David 
Neal 
Theodore 
David 
Gary 
Michael 


Howard 


city 
Altamont 
Manchester 
Schenectady 
Westford 
Lakewood 
Norwich 
LOrignal 

N. Sprgfield 
Houghton 
Scottsville 
E. Rochester 
Warren 
Nahsua 
Perry 
Palmyra 
New Gloucesr 
Allentown 
Chicopee 
Republic 
Little Vally 
Mattapoisete 
Durham 
Lebanon 
Westfield 
Stamford 
Bedford 
Troy 
Windham 
Utica 
Methuen 
Littleton 
Dover 

Hull 
Wakefield 
Pen Yan 
Schuylervile 
Almond 
Astoria 
Manchester 
E. Freetown 
Hornell 
Saugus 
Brockport 
Williamsvill 
Hornell 
Hammondsport 
Chicopee 
Mill River 
Valatie 
Dover 
Stoneham 
Holland 
Pennellville 
Angola 
Moscow 
Brookfield 
Utica 

Dover 
Arcade 
Nichols 
Amesbury 


Dee eS eee eS eee SS aR SASS SRS RAS aR aa S aks 


home BBS 
WA2UMX 
WA1WOK 
KD1R 
NN2Z 
WI1FYR 
VE2FKB 
WA1FHB 


KA2TFC 
WB2WXQ 


KA3SFC 
KA1GOZ 
WB2WXQ 
WA2WXQ 
KAINNN 


K1IMEA 
N8FIS 
KA2TFC 
KA1THM 
WB1DSW 
WA1FHB 


W2RGI 
WAI1PHY 
WA2UMX 
KA1PEP 
WA2TVE 
KAIMGO 
K1UAQ 
WB1DSW 
NS1N 
K1UGM 
WB2WXQ 
WA2UMX 


KD6TH 
KB4N 
W2RGI 
KC2AZ 
K1UGM 
WB2WXQ 


KC1AZ 
WB2GZE 
K1IMEA 
WA2PVV 
WB1DSW 


K1UGM 
KA2MZC 


WAOPTV 
K3RLI 
WA8LVP 
WA2TVE 
WB1DSW 
WB2ZUF 


exp mem 
9204 V 
9201 Q 
9105 Q 
9202 Q 
9105 Q 
9108 Q 
9203 Q 
9201 Q 
9205 V 
9106 Q 
9106 Q 
9111 V 
9204 Q 
9205 Q 
9111 V 
9106 Q 
9110 Q 
9204 Q 
9111 Q 
9111 V 
9107 Q 
9105 Q 
9202 Q 
9203 Q 
9105 Q 
9105 V 
9112 V 
9201 Q 
9112 V 
9202 Q 
9202 Q 
9202 V 
9107 Q 
9111 V 
9205 Q 
9202 V 
9107 V 
9204 Q 
9203 Q 
9302 V 
9205 Q 
9201 Q 
9203 Q 
9111 Q 
9106 Q 
9107 Q 
9110 V 
9203 V 
9211 V 
9111 V 
9107 Q 
9205 Q 
9107 V 
9205 V 
9204 Q 
9205 Q 
9201 V 
9203 Q 
9108 Q 
9204 Q 
9105 Q 
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TheNET Sysop's Help Sheet 


Parameter Function 

Minimum Quality For Auto Update 
HDLC Channel Quality 

RS-232 Channel Quality 
Obsolescence Count Init Value 


Obsolescence Count Min For Broadcast 


Nodes Broadcast Interval (sec) 
FRACK (sec) 

MAXframe 

Link RETRIES 

Digipeating 0=no; l=yes 
Validate Callsigns 0=no; 1l=yes 
Host Mode Connects 
TxDELAY (10ms) 


Broadcast Via Port b0=radio; bl1=RS-232 


Point Node Propagate 0=no; l=yes 


Connect Command Enable 0=no; 1=yes 


Destination List Length 

Time-to-live Initializer (hops) 
Transport Timeout (sec) 

Transport RETRIES 

Transport ACK Delay (sec) 
Transport Busy Delay (sec) 
Transport Window Size 

Congestion Control Threshold 
No-Activity Timeout (sec) 
P-persistance (see text) 

Slot Time (10ms) 

Link RESPTIME [t2 timeout] (10ms) 
Link T3 Timeout [CHECK] (10ms) 
Station ID 0=msgs;1=after; 2=al ways 
CQ Broadcasts 0=no; 1=yes 

Heard List Length 

Full Duplex 0=no; 1=yes 


Gateway Construction 

To construct a gateway, parameters 
must be set as shown. In addition the 
node being gatewayed to must be 
locked in as a node by the following 
command: 
N callsign + node 50 0 0 
callsign 

At each of the other nodes in the 
node stack of your gateway port the 
route to the gateway port must be 
locked to 0 using the command: 
R 1 callsign + 0 

The gateway port must be locked in 
at least one of the other nodes in your 
node stack. Performing these various 
locks prevents any potential abuse of 
the NEDA network by outside users or 
sysops. The specific abuse would be 
that of locking in NEDA nodes at the 
outside node with a route towards the 
gateway node. 

There are certain parms and con- 
figurations in a gateway TNC that are 


Parm # for version PROM Defaults NEDA NRS Defaults 
v1.1 v1.16 TN2.08 User Bkbn User Bkbn Gateway 

2 1 50 50 50 50 50 

Ss 2 50 58 50 230 50 

4 3 230 58 230 230 230 

5 4 3 3 3 3 3 

6 5 4 1 4 1 4 

7 6 1800 1800 1800 1800 1800 
18 7 6 1 3-6 a 1 

19 8 1 i 1 1 1 

20 9 10 10 8T 10 10 

23 10 0 0 0 0 0 

24 11 1 1 1 1 1 
na 12 0 0 0 0 0 
na 13 35 35 35 custm custm 
na 14 Z 3 2 3 3 
na 15 0 0 0 0 0 
na 16 1 1 1 0 1 

1 17 100 100 100 100 100 

8 18 18 18 18 18 18 

g [19] 300 300 300 300 300 
10 [20] 2 me Pe # 2 

11 {21} 1 1 rs 1 1 

12 [22] 180 180 180 180 180 
13 [23] 4 4 4 4 4 

14 [24] 4 4 4 4 4 

15 [25] 7200 7200 7200 7200 7200 
16 (26] 64 255 64 255 255 
17 (27] 35 1 35 1 1 

21 [28] 75 20 75 20 20 

22 [29] 65000 65000 65000 65000 65000 
25 [30] 1 0 1 0 0 

26 [31] 1 0 1 0 0 
na [32] 20 20 20 20 20 
na [33] 0 0 0 0 


like a user port and other parms and 
configurations that are like a backbone 
port. 

This kind of gateway is what is in 
use between SRTOGA and ALBANY 
and between ICRC07 and BERK. The 
nodenames on each end are visible. 
Stations must connect directly to the 
node on the far side of the gateway 
from where they are starting. Using 
the parms presented above on both 
sides of the gateway will force users to 
connect to the nodes on both sides of 
the gateway before proceeding. 

The parms listed above as PROM 
defaults for backbone nodes will cause 
a different type of gateway to exist in 
which the user ports at the multiport 
nodes on each side will show up at the 
user port on the other side. It is im- 
portant to note, however, that the node 
op on either side can cheat the gateway 
by locking in nodes on the other side 
that aren't propagated automatically. 


Thus that 'gateway’ is only a gateway 
if the sysops agree not to cheat. The 
first example is impervious to such 
cheating. 

The reason that the PROM defaults 
are set for gateway style operation is 
that it is up to the NRS to enable a 
backbone link in the NEDA network. 
If a node op installs a prom burned 
with these defaults the backbone will 
be a gateway until the NRS sysops it. 


Propagation Values 
Quality values at each node allong 
a broadcast sequence. 


This node: 256, 230 
2nd node: 207, 186 
3rd node: 167, 150 
4th node: 135, 121 
5th node: 109, 98 
6th node: 88, 79 
7th node: 71, 64 
8th node: 58, 52 
—KA2DEW 

—NEDA editor 
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North East Digital Association 
Western New York Region user port map 
rev 1.33 5/23/91 


To get to W2HPF 
Dx Cluster from 


the network, 


NEDA 

Box 563 
Manchester, NH 
03105-0563 


we connect to RDXA 
ae then connect to 
e W2HPF 
wv 
: ° = 
eon 
Ontario /“ Bie 
yee a 
- petites <<? eae 
Pi en ht ie ee ROCHMY:K2JD-1 :145.03 
We Petco am RR a Rochester, NY = === to NEWARK node 
yes ee es aoe" IPROCH : WE2B: 777 
ye atl a eee Experimental TCPIP Gateway 
PS Sacrecambe * 
” or" 
evebesussascs=eee ns ‘7a BREPT1: WB2VPH-1:147.?7 MONROE : WB2GWR-1:144.97 
a ne mee tee SENS nul ae ener oe Rene _peeeun, te W2HPF 
aa iow sain y McC to AUB node 
oa Se & SS a 
a 2° BUYYLOoWREPLN-1:144.99 4 6 e 
¢ Oe y i) 
: my ae eo 
By yA & CANDGA : WB2JLR-1:144.99 
A 
0° ~ = \ CANDG2 : WB2JLR-5: 445.6 
o :KD2DL-1:<no 2m rig yet> Canandaigua NY 
Weathersfield NY 
To get to WB2WXQ BBS i 
m the network, | 
connect to CANDG2 ] 
then connect toWB2WXQ 
To get to NM3G | to COR node 
BBS from the 
network, connect to | 
: SHERM2 thm 
T) get to WA3TUP connect to NM3G | 
Dx Cluster from 
the network, | 
connect to 
WPADXC than | 
ernecte ALFRED : K2BVD-1:144.95 1 
n= = To get to KC2AZ BBS 
PRKVIL: KA2TFC-2:144.97 erp ian 7144.97 from the network, 
ee connect to BBSSAZ 
BHERMM :W2TYG-3:145.07 = then connect toK2SAZ 
BHERM1 :W2JYG-5:441.0 
BHERM2:N27YG-2:440 BBS accesall 


ree | 
I J 
Eaten aI 
’ s r 
® 
ERIIP : WA3USH-4: 7777 & | 


WARREN : WBSIWY-1:145.69 
WRNLAN : WES IWY-3:144.90 
WRN2 :WB3IIWY-2:441.05 


To get to KA2TFC 
from the 
network, conncct to 
WRN2 then 


connect to KA2TFC 


New York 


Pennyslvania 


NEDA nodes are: 
BUFFLO BRKPT WXFLD 
CANDGA MONROE ELMIRA 


ALFRED FRKVIL WARREN 
SHERMN ROCHNY 


To enter or leave the NEDA network via 
an outside node you must single step 
across the link. (See NEDA membership 


package for info regarding TheNET 
nodes) 


Via Repeater 


Protected HTS free backbone 
Unprotected non 2 meter links 


Denotes baud rate of link, 
1200 if not shown 
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North East Digital Association 


Central New York Region user port map 
rev 1.33 5/23/91 


Box 563 
Manchester, NH 
WA2TVE Dx Cluster 
from the network 
connect to DXCLUS 
then connect toWA2TVE 
To use CD ROM 
yg SERVER 
en use 
- oa DXCluster command 
to ROCHINY am any gq NEWARK: WAZAAZ-1:144. 95 SHOW/BUCK call 
frien the Heewied 
rom the network, 
a SYRCUS: WA2VAM-9:145.59 connect to UTICA 
.¥ o @ Syracuse NY = my then connect toBBSTVE 
OF atten Tm PE I ibs é 
oe phat LAKE :KC3BQ-1:145.01 Utica NY We bine "a, a KNOX 
Skaneateles NY ee 
. ? 

: Fi CHERRY <No user port yet> 
RUBRNZ :Wescael 1223.38 ? Cherry Valley NY 
Auburn NY ¢ 

CNY145:N2IDK-9:145.09 
Pompey NY 
r 
| 
| 
CANDGA node A 
| 
| 
| 
| 
| 
| 
HOMER] : WA2VAM-7:145.07 
HOMER2:N2IDK-1 :145.57 
Babel 
& 
Py é& 


~ COR144:WA2VAM-1:145.01 
Cortland NY 
FLRGOBL 


ee ee ee ee ee oe es os es  t(O STMFRD node 


To enter or leave the NEDA network via 
NEDA nodes are: an outside node you must single step 


NEWARK AUB SYR HOM across the link. (See NEDA membership | 
COR LAKE CNY UTICA ina Rae TheNET 


CEE: Nia Repeater 


= as = = Protected HTS free backbone 
Unprotected non 2 meter links 


Denotes baud rate of link, 
pa) 1200 if not shown 


N.E.D.A. Quarterly v2.2 page 42 


North East Digital Association 


Eastern New York Region user port map 


rev 1.33 6/4/91 


GFL :N2AYY-1 
WA2UMX bbs Glens Falls, N 


S. C. Races 


Connect to ALBNY3 


2145.01 
NY 


NEDA 

Box 563 
Manchester, NH 
03105-0563 


then C SRTGA on 
then C BBSUMX 0 | 
SRTGAS:no user port ¢ i 
Saratoga NY < | 
S.C.RACES : 
ee | Full Service BBS NY 
SEMO STATE EOC 
at ALBANY 
; ee Connect any NEDA 
Local Area SRTGA1:WA2UMK-1, :145;01y Port O° ALBANY node in Eastern NY 
EMERGENCY LAN SRTGA2:WA2UMX-12 :221.17 USER/BBS port i i Then C NYEOC 
lease restrict use Se aeatan NY ; : Pe Intermittent Link 
SCH145:K2AE-1:145.09 ar eN eda: 
Schenectady, NY 
® WMA :KIFFK :145.05 
x NYSEMO:KB2CS-2 :145.09 Magee picckaheia & 
® NYEOC :KB2CS-4 :BBS ‘HARE 
Ss % Albany, NY 


KNOX :WB2QBQ-1 :144.91 
DXKNOX: K2TR-1 7223.54 

to CHERRY = = crow :WB2QBQ-7 :mini-conf 
NYDX10:WB2QBQ-10:28.195 “@@ my 
Knox, NY ay 


To get to K2TR Dx 
Cluster from the 
network, connect to 
DXKNOxX then 
connect to K2TR 


STMFRD : KB2CS-1:145.77 


CROWD : KB2CS-7:mini-conf 
toCOR a= ™ Stamford NY = ay ey 


To enter or leave the NEDA network via 
an outside node you must single step 
across the link. (See NEDA Memeersnip 
penne e for info regarding TheNE 
nodes 


Hoo Via Repeater 


= === Protected HTS free backbone 
Unprotected non 2 meter links 


Denotes baud rate of link, 
1200 If not shown 


NEDA nodes are: 


ALBANY CLV KNDRHK Full Service BBS 
KNOX WMA NYSEMO NOUCOMMT CEG: 


% 


~ 


1 a 


4 


4 Note:ALBNY2:WA2WNI-2 
4 User Port for Novice/BBS/TCP/IP a 


ALBNY3:WA2WNI-3:Gateway Port to SRTGHY 
ALBANY : WA2WNI-1:144.93 
ALBNY2 : WA2WNI-2: 223.58 o 


West Go NY o 
| a 


| 

1‘ a 
| 

x rf 


Intermittent Link 


Full Service BBS 
Regional Gateway 
NET40:WA2PVV 
Connect to any 
NEDA node in 
Eastern NY Then 


y 
my ENDREK:KB2CCC-1 :144.99 C NET40 
KND220:WA2PVV-2 :224.98 
Valatie, NY 
SX KINDER: WA2PVV-7:145.05 
A KINDER: WA2PVV-7: 220.57 to CHSTR node 
4 NET40 :WA2PVV :BBS oe 


Kinderhook NY s 
el oo 
a a 


\ Mini BBS at NY 
4 SEMO SOUTHERN 
DISTRICT OFFICE 
4 Connect CLV 

‘ Then C K2RKV-4 
1 
4 
t 


Poughkeepsie, NY 
g 145.09 


CLV ?=N2CJ-1:145.09 
CLV440:N2CJ-3: 438.425 
Lagrangeville NY 


PKPSIE:WB2COY-12:145.09 
PKPSIE:WB2COY-12: 438. xx 
PKPSIE:WB2COY-12:221.11 


One method of connecting to the 
network from NYC, NNJ, and LI is 


PKPSIE:WB2COY-12:221.17 to find N1DCS~2:haven, then 
BBSCOY : WB2COY : BBS connect to PUT, then PKPSIE, then 
Poughkeepsie NY CLV440, This allows a station to. 


get into the network without going 
over 2 meters (2 meter hops cause 
serious problems in reliability) 
Most nodes in NNJ and NYC know 
about N1DCS~2:haven. 


to PUT node 


SCH145 STMFRD Connect any NEDA to ENY node 


node in Eastern NY 
Then C BBSCOY 
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North East Digital Association 


VT/Western Mass/CT user port map 
rev 1.32 5/23/91 


To enter or leave the NEDA network via NEDA / 
an outside node you must single step Box 563 / 
across the link. (See NEDA membershi 7 
package for info regarding TheNET - Manchester, NH é 
degen 03105-0563 / 
anon Via Repeater / 
= a es mw Protected HTS free backbone / 
Unprotected non 2 meter links A 
Denotes baud rate of link, : 
"1200 Ifnot shown y 
Vermont / 
NEDA nodes are: / 


seh ncaa CENT = ee 


| 7 to SWNH node 
a 


of} = gw toSNH node 
asset 
ea es 
os” i 
es 
o*  ] 
[255] team pair? 
| 20220 eSniarh ¢? ' 
* Mt. Gr Ma ? 
ly ? 
¢ a 
Oe 1 4 
¢ ¢ 
oa ys 
to KNDRHK node iM pas: Kia 4:308 
| a 110505 esos CENTHA: KALOXQ-1:145.07 
2:223 CMA111 : KALOXQ-2: 221.11 
STMER | Cesee: KLM? 114499 rect 
o Mah a St suits ~e 
SPFLD: W1WY-1:145.01 
® SPPLD2 :WLMY-2 : 223. 48 
H & coe BBS: WLI: 
©, g St MA 
BERK :WALTPP-3:trassfer polat 
Gaile, MA 
BQ 
| a 
| 
| mar me Massachusetts 
ENY node | ERK maize P-3 : rates .07S dn 446.078 oat 
te . BEDKS :MAIEPP-16,145.09 
| DERKA :WA1TPP-9 :145 
' MA 
mm oming north connect to BERK2. 
oe south start from BERK2, 


connect to CONNCT:WA1 UQC-8 
(ICRCO7's 221.05 port) 


Connecticut 


to 
NJ, CT , Rl, NYC 
nodes 
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North East Digital Association 


New Hampshire user portmap NEDA 


rev 1.32 5/23/91 Box 563 
‘Manchester, NH 


03105-0563 | 

To enter or leave the NEDA network via 
an outside node you must single step | 
across the link. (See NEDA pembarenip yA 
package for Info regarding TheNE ‘ | 
Hodes / | 
mies Via Repeater i | 
=z ues = Protected HTS free backbone | ‘ 

Unprotected non 2 meter links ia | 

Denotes baud rate of link, ‘ 

1200 If not shown Vhs : 
NEDA nodes are: va | 
SWNH VNH CENTNH y i 
BELNAP NHOEM MTUNC 4 . 

SNH NARC_ KNGSTN / New Hampshire i 
NSHORE yi : 
7 Tb get toNH 
: OFFICE of | 
i, EMERGENCY 
/ MANAGEMENT | 
/ apse annet eekeghnegicn ice a? oo i 
m an 
VNH 1 WA1LTLN-1:144 as NEDA node in | 
ager a, x i | 
bye, a ee i | 
i / — | ! 
1/ Pe | 
vs as es ao ER SMOUTMIREEST nin icsced ' 
| ouaa™ [asoof ™ Stn OM 
Ve rmont ) = women nf beer ses 65 03 ai Ae get to Maine 
NHOEMS 1 WA1WOK-3:223.58 rom the network, 
: on gt Sees 
onco 8 
vA | Ba State OEM pet ete 4 | connect to NHNET 
Vin | y, G8 NB, PENNS) fi | 
ie) | 
To get to W1FYR / n je a : a 
eee / a NM1D Stee bargrenr AEE i KNGSTW:WB1DSW-5 1145.05 
Snivie a 7S DOSgate™ ; | SA eee 
connect to / | 4 Connect to SNH | Kingston, NH ¢ 
WI1FYR-1 U I a and then C NM1D-2 . 
A i a * i 7 \ Rw 
/ I g Spe by Catr ‘ 
/ 4 ASH = 1KB4N-5:145. SuuUM KL TR-21442 ,025 
‘ | ? bereft phere bie posses Mane -95 ; % 
ve | i Nashua NH - G8 i } NSHRaZKCIPK-2273.98 
uh ' a NARC sKALGOS 953.44), 99 . 
a ; BBSGOz :KA1GOS~-1: BB ” 
7 teleci Seer Ey PT 05 Reena Ge/TheNeT : 4 
vs SS is soy eeereectiter 
i ’ a. ose freer 
, 
es Go 
& 
i Massachusetts Chases fom the 
Ps. network, connect to 
’ roe so ie KER 
connec MBOS uh gt de Sas eer 
4 to CHSTR node @ @ teos inicatites.63 


to NCMA node | to CENTMA node —. ae te 2400 baud 


(to Eastern + S E Mass and Rl) 
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North East Digital Association Membership 


Welcome to packet networking. 
This is the official membership appli- 
cation form for N.E.D.A. 

Some General Stuff About N.E.D.A: 

N.E.D.A. was founded on Sept. 17, 
1989. N.E.D.A. holds 5 scheduled 
yearly meetings including four board 
of directors meetings announced one 
month in advance and one general 
meeting each fall in a central location 
to be announced at the previous board 
meeting. The general meeting is open 
to all. The board of directors meeting 
is open to voting members only, all of 


Membership Application 
Name: ee 


address: s 
City, State or r Province: 
: Home BBS: : 


Have you used the network? 


Do you own more than 1 TNC? 


On what bands do you operate packet? 


RCT: 


whom are invited via packet mail @ 
their Home BBS. 

Club funds may only be allocated at 
the board meetings, the minutes of 
which are printed in the NEDA Quar- 
terly. 

The board of directors consists of 6 
hams who are elected for 2 year terms 
by the voting membership. The board 
of directors appoints an editor, chair- 
person to the general meeting, trea- 
surer plus any additional department 
heads as they see fit. 

The dues structure of NEDA is as 


What's the furthest you've packeted on VHF/UHF terrestrial packet? 


follows: 

Associate network support mem- 
bership is $10. Associate network 
support membership with quarterly 
updates is $15. Voting membership in 
N.E.D.A. is $25. Voting members de- 
cide which 3 members will be ap- 
pointed to the board of directors at the 
general meeting. (pending constitu- 
tional review at July board of directors 
meeting) 

Non US memberships will be asked 
a surcharge to cover postage and 
banking fees. 


What kind of terminal or computer do you use for packet? 


Are you interested in assisting in network development? 
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